OmniAgent est un framework d’agent IA qui promet de s’auto améliorer et de durcir la sécurité pendant l’exécution. Mon verdict court : ça mérite un essai si vous aimez tester des agents de dev, mais ce n’est pas encore un outil que je laisserais corriger du code sensible sans revue humaine.
Je l’ai installé, lancé avec un vrai proxy LLM compatible OpenAI, puis utilisé sur un mini cas de sécurité applicative : corriger un fichier Python volontairement vulnérable, exécuter les tests, et observer ce que l’agent produit réellement.
OmniAgent, c’est quoi ?
OmniAgent se présente comme un agent open source capable de travailler sur des fichiers, d’appeler des outils, de mémoriser des apprentissages, de faire de la réflexion après échec et d’appliquer des garde fous de sécurité.
Dans le README, les mots clés sont ambitieux : OmniEvolve, Hyper Harness, Deep Reflexion, Guardian, Sentinel. En clair, l’idée est de dépasser le simple chatbot qui répond du texte. OmniAgent veut lire le dépôt, modifier des fichiers, lancer des commandes, apprendre de ses erreurs et contrôler les actions risquées.
Pour un freelance sécu ou DevOps, la promesse est intéressante : donner à l’agent une tâche concrète, par exemple auditer un script, corriger une faille simple, puis lancer les tests. C’est exactement ce que j’ai essayé.
| Élément | Détail observé |
|---|---|
| Dépôt testé | YeQing17-2026/OmniAgent |
| Commit testé | 4d22e25b5d87998f344e5fc9d4328dc1d7e72788 |
| Langage | Python 3.11+ |
| Installation | pip install -e . |
| LLM utilisé | Proxy OpenAI compatible, modèle openai/gpt-4o-mini |
| Interface testée | Exécution Python programmatique de l’agent, avec outils fichier et bash |
| Tests du dépôt | 33 passed in 0.88s |
Installation de OmniAgent
J’ai cloné le dépôt dans /tmp, comme prévu pour un test jetable, puis j’ai installé le package en editable. Dans mon environnement, /tmp ne permettait pas de charger certaines extensions Python compilées depuis un venv, donc j’ai gardé le clone dans /tmp mais créé le venv dans un dossier temporaire exécutable. Ce n’est pas un défaut d’OmniAgent, plutôt une contrainte de sandbox.
Les commandes importantes :
git clone https://github.com/YeQing17-2026/OmniAgent /tmp/omniagent-scout
cd /tmp/omniagent-scout
python -m venv /root/omniagent-venv
. /root/omniagent-venv/bin/activate
pip install -e . pytest
pytest -q
Résultat côté dépôt :
33 passed in 0.88s
Pour le LLM, je n’ai pas cherché de clé réelle. J’ai utilisé le proxy local fourni, avec une configuration OpenRouter compatible :
export OPENAI_BASE_URL=http://172.17.0.1:8790/v1
export OPENAI_API_KEY=sk-proxy
export OPENAI_API_BASE=http://172.17.0.1:8790/v1
export OPENROUTER_BASE_URL=http://172.17.0.1:8790/v1
export OPENROUTER_API_KEY=sk-proxy
Dans la config Python, j’ai forcé openrouter, openai/gpt-4o-mini et http://172.17.0.1:8790/v1.
OmniAgent à l’usage : mon vrai scénario
J’ai créé un fichier Python volontairement faible :
import hashlib
import os
import subprocess
USERS = {
"admin": hashlib.md5(b"password123").hexdigest(),
}
def check_password(username, password):
return hashlib.md5(password.encode()).hexdigest() == USERS.get(username)
def list_file(user_supplied_path):
return subprocess.check_output("ls " + user_supplied_path, shell=True, text=True)
Le cas d’usage donné à OmniAgent était simple, mais pas décoratif : auditer ce fichier, le durcir sans changer les noms publics, puis lancer pytest.
OmniAgent a bien utilisé ses outils. Je l’ai vu appeler find, read_file, write_file, bash, puis demander une approbation pour exécuter pytest. Il a remplacé l’appel shell dangereux par un appel en liste, ajouté une validation de chemin, et tenté de migrer le hash de MD5 vers SHA-256.
Le premier résultat est mitigé. L’agent a vraiment écrit le fichier, il a vraiment lancé les tests, mais il a cassé le login : check_password utilisait SHA-256 alors que le dictionnaire USERS contenait encore le hash MD5.
Le point qui m’a gêné : malgré un pytest rouge, le résultat de l’agent avait success: True. Il expliquait bien l’échec dans son texte, mais le statut machine n’était pas aligné avec la réalité du test. Pour de l’orchestration automatique, c’est le genre de détail qui compte beaucoup.
J’ai ensuite donné une deuxième instruction : corriger le hash stocké et relancer pytest. Cette fois, OmniAgent a modifié la ligne concernée, lancé les tests, et obtenu :
test_vuln_app.py .. [100%]
2 passed in 0.01s
Ce que j’aime dans OmniAgent
Le premier bon point, c’est que le projet s’installe proprement. Les tests du dépôt passent, les dépendances sont classiques, et le code est assez lisible pour comprendre le chemin d’exécution.
J’aime aussi l’approche outils natifs. L’agent ne s’est pas contenté de me répondre avec des conseils. Il a lu le fichier, édité le fichier, lancé une commande, puis intégré la sortie de pytest dans sa réponse. C’est le minimum attendu pour un agent de dev, mais beaucoup de projets GitHub très marketés ne vont pas jusque là.
Autre point positif : le système d’approbation autour de bash existe vraiment. Dans mon test, l’exécution de pytest a été classée comme action nécessitant validation. Pour un agent qui touche à des fichiers et exécute des commandes, ce garde fou est nécessaire.
Enfin, la boucle de rattrapage a une base utile. Quand je lui ai signalé le problème, OmniAgent a trouvé rapidement la correction et a validé par test.
Les limites de OmniAgent
La limite la plus visible est la maturité. Le README vend un agent très avancé, mais mon test montre surtout un agent de codage fonctionnel, encore fragile sur la notion de succès réel.
Le premier passage a produit un correctif incomplet. Ce n’est pas dramatique, les agents font souvent ça, mais le statut success: True alors que pytest échoue est plus problématique. Un orchestrateur DevOps doit savoir remonter un échec comme un échec.
Le correctif de sécurité reste aussi perfectible. Passer de MD5 à SHA-256 brut n’est pas une vraie stratégie moderne de stockage de mot de passe. Il aurait fallu parler de sel, de bcrypt, argon2 ou hashlib.pbkdf2_hmac. La validation de chemin par startswith(os.getcwd()) est également fragile dans certains cas de chemins préfixes. Pour un outil qui promet le durcissement dynamique, j’attendais une réponse plus rigoureuse.
Dernier point : beaucoup de concepts annoncés semblent encore difficiles à juger sur un petit cas. Guardian, Sentinel, évolution de mémoire, apprentissage du modèle, tout cela demande des scénarios plus longs pour être validé sérieusement.
Est-ce que OmniAgent marche vraiment ?
Oui, au sens pratique : il s’installe, il appelle un LLM via base URL custom, il lit et modifie des fichiers, il exécute des tests, et il peut corriger une erreur après feedback.
Non, si l’on interprète la promesse comme un durcisseur autonome fiable. Sur mon test, il a fallu une deuxième passe humaine pour arriver à un état vert. Et même à la fin, je relirais le patch avant de le garder en production.
Pour moi, OmniAgent est aujourd’hui un prototype sérieux d’agent de développement, pas encore un copilote sécurité autonome.
Faut-il adopter OmniAgent ?
Mon verdict : essayer, mais ne pas adopter en production sans garde fou.
OmniAgent peut être utile pour explorer un dépôt, automatiser des tâches locales, prototyper des workflows agentiques, ou construire un assistant interne qui manipule du code sous supervision. Il est moins adapté si vous cherchez un scanner sécurité fiable, déterministe et prêt à intégrer dans une CI.
Je le classerais dans la catégorie « à surveiller ». La base est réelle, le produit tourne, mais le marketing va plus vite que la robustesse observée sur mon cas.
FAQ
OmniAgent est-il utilisable sans clé OpenAI réelle ?
Oui, si vous disposez d’un endpoint compatible OpenAI. Dans mon test, le proxy local a suffi avec OPENAI_BASE_URL, OPENROUTER_BASE_URL et une clé factice.
OmniAgent remplace-t-il un audit de sécurité ?
Non. Il peut aider à repérer et corriger des problèmes simples, mais ses corrections doivent être relues. Sur mon cas, il a d’abord cassé un test et a proposé un durcissement incomplet.
Pour qui OmniAgent est-il le plus utile ?
Pour des développeurs, DevOps et freelances sécu qui veulent expérimenter des agents capables d’agir sur un workspace. Il faut accepter de superviser les commandes, relire les patchs et garder des tests automatisés.