La version 8.0 de Tryton s'inscrit dans la continuité des versions précédentes en améliorant la stabilité, les performances et les fonctionnalités (dont ci-dessous les principales).
Cette version a un support long de cinq ans comparé à une année pour version précédentes.
Quand un champ a été modifié par les actions de l'utilisateur, il est identifié afin de permettre une vérification visuelle avant de sauvegarder.
Les onglets peuvent être réorganisés maintenant aussi pour le client web et l'action de déconnexion est désormais dans le même menu qui contient déjà les notifications et les préférences utilisateurs afin de donner encore plus d'espace dans l'entête pour les onglets.
Modules métiers
Sur le plan fonctionnel, la version 8.0 s'enrichit avec de nouveaux modules : gestion des chèques, gestion des accises et suivi d’alcool ainsi que le suivi de la vente de service par des tâches de projet.
Les modules comptables espagnols et allemands ont été sortis du dépôt standard afin d'être gérés plus simplement par la communauté.
Administration et développement
La version 8.0 ajoute le support de Python 3.14 et arrête celui de Python 3.9.
La librairie psycopg est mise à jour à la version 3 ce qui permet d'envoyer les requêtes SQL et leurs paramètres séparément et ainsi lever les limitations sur la taille des paramètres (entre autre le nombre d'IDs dans les clause column IN (...)).
Il est maintenant possible de définir des champs Function (c-à-d calculés par l'ORM) uniquement par une expression SQL. Cette expression sera utilisée pour la lecture, la recherche et le tri.
La définition des modules a été améliorée pour permettre l'utilisation de sous-répertoires plus facilement. En effet, on peut maintenant créer un fichier tryton.cfg dans un sous-répertoire et utiliser un chemin relatif depuis celui-ci vers ses fichiers ressources.
Une API REST a été ajoutée au serveur et une librairie cliente naiad a été publiée. Elle permet de remplacer l'utilisation du module trytond directement pour la création d'applications connexes telles que des sites web. C'est une architecture plus flexible que celle utilisée jusqu'à maintenant comme dans le module flask-tryton.
Les sessions pour le client web sont maintenant stockées comme cookie pour plus de sécurité.
Le client web utilise à présent uniquement des chemins relatifs, ce qui permet de le servir depuis un sous-répertoire.
NB : je n'ai absolument pas compris ce que je renvoyais comme données.
Pour moi :
rfn = fonction appelée
rit = temps passé dans le frame où la fonction est appelée
ct = temps passé dans le frame parent (?????)
pfn = fonction appelante
Écrire un script spécifique à yahi
Ensuite après avoir récupéré les journaux d'un profilage, il faut écrire un script de sélection des données.
Ici ; on ne souhaite qu'inclure les entrées dont le chemin vers le fichier qui contient la fonction contient archery.
#!/usr/bin/env pythonfromyahiimportnotch,shootfromjsonimportdumpsfromarcheryimportmdictdate_formater=lambdadt:"%s-%02d-%02d%02d-%02d-%02d.%02d"%(dt.year,dt.month,dt.day,dt.hour,dt.minute,dt.second,dt.microsecond)######################## Setting UP ################################### parsing command line & default settings. Return a not fully qualified objectcontext=notch(log_format="custom",off="geo_ip,user_agent",output_format="json",# ne sélectionner que les fonction dans le fichier archery/trait.pyinclude='''{ "from_callee" : ".*archery/trait.py" }''',date_pattern="%s",# datetime en format timestamp (spécifique à yahi) log_pattern="""^(?P<datetime>\S+)\s \('(?P<from_callee>[^']+)',\s (?P<lineno_callee>[^']+),\s '(?P<callee>[^']+)'\)\s (?P<time>\S+)\s (?P<ctime>\S+)\s \('(?P<from_caller>[^']+)',\s (?P<lineno_caller>[^']+),\s '(?P<caller>[^']+)'\)$""")# log sample# 1779465928.7602208 ('<frozen importlib._bootstrap>', 911, '_load_unlocked') 1 1.267900000000155e-05 0.0015263490000001073 ('<frozen importlib._bootstrap>', 1304, '_find_and_load_unlocked')##### OKAY, now we can do the job ##########################################context.output_file.write(dumps(shoot(context,lambdadata:mdict({'date_calls':mdict({date_formater(data["_datetime"]):float(data["time"])}),"by_overhead_callee":mdict({data["callee"]:float(data["ctime"])}),"by_overhead_caller":mdict({data["caller"]:float(data["ctime"])}),"by_time_callee":mdict({data["callee"]:float(data["time"])}),"by_time_caller":mdict({data["caller"]:float(data["time"])}),'by_callee':mdict({data["callee"]:1}),'by_caller':mdict({data["caller"]:1}),'by_transition':mdict({"%(caller)s=>%(callee)s"%data:1}),'by_transition_time':mdict({"%(caller)s=>%(callee)s"%data:float(data["ctime"])}),'total_line':1,}),),indent=4))
Plus de 25 ans après le lancement du fameux logiciel Aviméca, utilisé partout en physique-chimie au lycée, 18 ans après l'échec retentissant de PyMeca, je vous annonce avec grand plaisir que je lance le logiciel NeoMeca, dans sa première version.
Ce qu'offre NeoMeca par rapport à ses prédécesseurs :
1) Support natif du .MP4, .MOV, .AVI (rétrocompatibilité)
2) Interface plus esthétique bien qu'encore imparfaite
3) Export de données plus facile
Je suis conscient de n'en être qu'à la première version (1.0.0)
Je travaille activement sur une version 1.5 qui corrigera la majeure partie des bugs de la première version et améliorera l'interface.
PS : Le logiciel est codé en python sur +22,000 lignes. L'exécutable pèse 8Mo, +130 avec ses dépendances. Ce qui est un coût nécessaire au vu de ses performances.
J’ai longtemps eu une petite interface d’admin Django pour activer / désactiver la debug toolbar (même en prod), dans plusieurs projets, j’ai décidé de le packager :
Avant un paf /bin/ls faisait crasher le serveur, sniff… Je ne vois pas trop l’intérêt d’envoyer du binaire mais bon l’autoriser était un bon moyen de corriger le bug.
Avis à tous ceux qui vont hurler sur un projet vibe codé mais pour ceux qui veulent tester et que ça intéresse, j'ai créé ELY. Un agent IA auto-hébergé que je développe depuis plusieurs mois et même si j'ai fait ça avec Claude Code, croyez moi, je n'ai pas eu qu'à dire "Fais moi ceci, comme cela, qui fait çi et qui fait ça…". C'est le fruit de week-end et de soirées, voire nuits, à imaginer, tester, échanger jusqu'à ce que le résultat me convienne.
La particularité — et la raison d'être du projet — est un pipeline d'anonymisation des données personnelles qui s'exécute AVANT tout appel à un LLM, qu'il soit local ou cloud.
L'écosystème des agents IA a beaucoup grandi en 2025-2026 (OpenClaw, Hermes, et bientôt Google Remy à I/O 2026), mais aucun n'adresse sérieusement le cas des organisations soumises au secret professionnel ou au RGPD strict. ELY essaie de combler ce vide.
Quand un avocat copie une note de synthèse dans ChatGPT, ou qu'un expert-comptable demande à Claude de résumer un compte de résultat client, les noms, IBAN, SIRET, montants — tout part en clair vers des serveurs aux États-Unis. C'est documenté, c'est connu, c'est pourtant fait quotidiennement par des centaines de milliers de professionnels en France.
Les agents auto-hébergés actuels (Hermes, OpenClaw, Aider) règlent le problème de la "boîte noire" en mettant le code à disposition, mais ne résolvent pas le problème des données : si l'agent appelle Claude ou GPT-5 en backend, les données partent quand même.
ELY ajoute une couche d'anonymisation déterministe en amont : avant toute construction de prompt, un SecurityFilter détecte et remplace les PII (emails, IBAN, SIRET, numéros de téléphone, jetons API…) par des placeholders. Le LLM voit [EMAIL_0], [IBAN_0]. Les valeurs réelles sont restaurées localement quand la réponse revient à l'utilisateur. Le LLM ne voit jamais la donnée brute.
Architecture
ELY est construit sur :
- FastAPI + LangGraph (backend Python)
- Next.js 16 (frontend)
- Apps natives iOS (SwiftUI) et Android (Kotlin/Compose)
- Daemon Go pour l'automatisation desktop
- Qdrant pour la mémoire vectorielle locale, SQLite FTS5 pour le keyword
- Docker Compose pour le déploiement
Le routage LLM se fait par "tier de complexité" (Tier A rapide / B standard / C profond / IMG / SYS). L'utilisateur assigne un modèle à chaque tier dans les Settings — local (Ollama, LM Studio) pour les tâches simples, cloud (Mistral privilégié, ou Anthropic, OpenAI, Gemini, DeepSeek, Qwen, etc… selon préférence) pour les complexes. Tout est configurable sans redémarrage.
HITL (Human In The Loop) structurel
Toute action irréversible — envoi de mail, suppression, commande SSH, partage — passe par une validation explicite. Trois choix : autoriser une fois, refuser, ou bannir définitivement (la décision persiste entre toutes les sessions futures).
C'est différent des "confirmations" qu'on trouve sur les agents cloud type ChatGPT Operator, où le HITL est une UX optionnelle. Chez ELY, c'est structurel — désactiver HITL demande une modification du code source, ce qui est explicitement interdit par la licence.
Licence
ELY est sous licence PolyForm Strict 1.0 — source-available, gratuit pour usage personnel/familial/éducatif, licence commerciale annuelle pour les entreprises.
C'est un choix conscient, je l'assume :
l'open-source au sens OSI ne permettait pas de pérenniser le projet sans capital-risque, et la licence MIT/Apache aurait permis à un acteur cloud US de forker pour son SaaS sans aucune contrepartie (J'ai déjà donné…).
Ce modèle source-available est devenu courant (Sentry, Grafana, Elastic) et fonctionne bien pour les projets entre solo-dev et fondation.
Trois commandes, 30 minutes pour le scénario "POC local" avec une clé API Gemini gratuite. Documentation et scénarios de déploiement plus avancés (Cloudflare Tunnel, Tailscale, multi-canaux) dans docs/START_HERE.md.
Discussions et critiques bienvenues
C'est un projet personnel développé en parallèle de mon activité professionnelle (je suis directeur technique chez un gros intégrateur Français, spécialisé webtoprint). Le code est ouvert, les choix architecturaux documentés. Toutes les critiques techniques sont les bienvenues, c'est ce qui fait monter le niveau, du moment que c'est constructif.
Page de test EscapeCyber Bonjour,
Je souhaite présenter un petit projet personnel : un générateur de mots de passe écrit en Python/Tkinter, compilé en standalone via Nuitka, et destiné à fonctionner directement depuis une clé USB (Ventoy).
**Origine du projet**``
Comme beaucoup d’utilisateurs, j’en avais assez de :
devoir créer des mots de passe différents selon les sites,
me faire refuser un mot de passe pour un symbole manquant,
revenir sur “mot de passe oublié”,
recommencer plusieurs fois sur différents services.
J’ai aussi constaté que beaucoup utilisent encore des mots de passe basés sur des données personnelles (chien, date de naissance, etc.), ce qui n’est ni sécurisé ni sécurisable.
L’objectif : un outil simple, portable, robuste, qui génère des mots de passe fiables sans prise de tête.
** Fonctionnalités**``
3 niveaux de complexité : simple (sans symboles), standard (symboles courants), avancé (tous symboles).
Longueur configurable : 6 à 32 caractères.
Disponible en 15 langues.
Génération aléatoire via un algorithme interne.
Protection par mot de passe à l’ouverture.
Utilisation de HMAC et bcrypt.
Compilation Nuitka standalone (pas de dépendances externes).
Fonctionne sur :
- Windows 7 → 11
- Linux Lite 7.04
- Ubuntu 24.04 LTS
et probablement la majorité des distributions.
** Comportement sous Linux (console automatique)**``
Lors du lancement du binaire standalone sous Linux, une console s’ouvre automatiquement, puis la fenêtre Tkinter apparaît. Ce comportement est normal avec Nuitka : le binaire reste considéré comme une application console + GUI, et Linux ouvre un terminal pour gérer stdout/stderr.
La console ne demande rien, ne nécessite aucune action, et le programme fonctionne normalement.
** Vision du projet**``
À terme, je souhaite ajouter un coffre-fort compartimenté (par lettre ou catégorie), afin d’éviter l’exposition d’un lot complet de mots de passe. Les personnes travaillant en cybersécurité comprendront l’intérêt : limiter la surface d’attaque.
** Distribution possible**``
Le projet se veut d’utilité publique. Il pourrait être distribué par :
banques,
assurances,
entreprises,
associations (ex : protection de profils exposés en ligne).
** Support**``
Une page dédiée sur mon blog documentera :
- les comportements selon les distributions,
- les limitations (ex : console automatique),
- les solutions,
- les mises à jour,
- un contact administrateur.
** Pourquoi je poste ici**
Je viens chercher :
- des retours techniques,
- des critiques constructives,
- des tests sur d’autres distributions,
- des avis sur la partie sécurité.
Projet personnel, développé par moi-même, sans IA. Merci pour vos retours.
Quelques captures pour illustrer le fonctionnement :
– lancement sous Linux (console + interface Tkinter)
– génération d’un mot de passe
– interface en différentes langues
– version Windows
– test de la fonction japonais (sans mot de passe sur cette machine) >
> 
