ITOps Agent Platform est une plateforme web open source qui promet d’orchestrer plusieurs agents IA pour automatiser l’exploitation IT. Après un vrai lancement local, un modèle branché sur un proxy OpenAI compatible et un test d’alerte Prometheus, mon verdict est clair : c’est intéressant à essayer en labo, pas encore à poser tel quel sur une production sensible.
ITOps Agent Platform, c’est quoi ?
ITOps Agent Platform vise un sujet très concret : transformer des alertes, des scripts, des serveurs et des workflows en une console d’exploitation assistée par IA.
Le projet se présente comme une plateforme chinoise de multi agents pour l’IT Ops. Dans l’interface, on trouve des agents prédéfinis pour l’analyse d’alertes, le diagnostic, les logs, la conformité, les changements, les rapports, la commande serveur et l’inspection réseau. Le tout tourne autour d’un backend Node.js, d’une base SQLite, d’un frontend React et de workflows visuels.
La promesse qui m’intéressait comme freelance sécu et DevOps : recevoir une alerte Prometheus ou Zabbix, demander à un agent d’analyser le contexte, puis produire un plan d’action qui distingue ce qui peut être automatisé de ce qui mérite une validation humaine.
| Élément | Ce que j’ai observé |
|---|---|
| Produit | Console web ITOps multi agents |
| Stack | Node.js, Express, SQLite, React, Vite, Socket.io |
| Déploiement documenté | Docker Compose ou exécution source |
| Test réalisé | Modèle OpenAI compatible, agent d’alerte, cas Prometheus |
| Résultat | Analyse structurée et enregistrée dans l’historique d’exécution |
Installation de ITOps Agent Platform
J’ai cloné le dépôt GitHub dans /tmp, lu le README et inspecté les scripts. Le chemin Docker est bien documenté, mais dans mon environnement de test Docker n’était pas disponible. Je suis donc passé par l’installation source, ce qui est un bon test de robustesse pour un projet web complet.
Première surprise : installer directement dans /tmp a échoué, car le binaire esbuild ne pouvait pas s’exécuter depuis ce montage. J’ai donc gardé le clone de référence dans /tmp, puis lancé l’installation source dans un répertoire temporaire sous la racine du test, supprimé ensuite.
Les commandes utiles ressemblaient à ceci :
npm run install:all
npm run build
NODE_ENV=development PORT=3001 node backend/dist/app.js
cd frontend
npm run preview -- --host 127.0.0.1 --port 8080
Le build a réellement compilé le backend TypeScript et le frontend Vite. Côté dépendances, npm a signalé des vulnérabilités : 13 dans le backend, dont 2 critiques, et 13 dans le frontend, dont 1 critique. Ce n’est pas forcément exploitable tel quel, mais pour une console d’ops qui manipule des accès serveurs, c’est un point à traiter avant tout usage sérieux.
ITOps Agent Platform à l’usage
Au premier démarrage, le backend a initialisé SQLite, créé l’utilisateur admin, chargé les agents et exposé /health. La réponse santé était exploitable : statut global healthy, base avec 61 tables, mémoire, CPU, taille de base, état WebSocket, état du scheduler et file de tâches.
J’ai ensuite changé le mot de passe initial, créé un modèle nommé Proxy OpenRouter scout, configuré sur une base OpenAI compatible locale, puis lancé un test de connectivité. Le produit a bien appelé le proxy et retourné : modèle connecté, latence autour de 1,3 seconde.
Le vrai test a porté sur l’agent d’alerte. Je lui ai envoyé une alerte volontairement réaliste : serveur api-prod-01, CPU à 94 %, load average à 8,7, taux de 5xx Nginx à 12 %. Je lui ai demandé de séparer les actions automatiques des actions nécessitant une approbation.
Le résultat n’était pas juste un ping de LLM. ITOps Agent Platform a exécuté l’agent, mesuré le temps d’exécution, incrémenté son compteur d’usage et enregistré l’exécution. La réponse produite contenait :
Gravité : haute
Causes possibles : bottleneck applicatif, fuite mémoire, pic de trafic,
service backend en défaut, erreur applicative ou configuration Nginx.
Actions automatisables : expansion si l'infra le permet, baisse temporaire
du trafic non critique.
Actions avec approbation : revue de code, optimisation Nginx, analyse APM
et logs détaillés.
Ce n’est pas une remédiation autonome complète. En revanche, pour un premier tri d’alerte, la sortie est propre, lisible et directement utilisable dans un ticket d’incident.
Ce que j’aime dans ITOps Agent Platform
Le premier bon point, c’est la largeur fonctionnelle. Même en local, sans serveur SSH cible, on voit que le produit ne se limite pas à une page de chat. Il y a des sections pour les serveurs, les workflows, les tâches, les scripts, les alertes, la connaissance, l’audit, les notifications, les modèles IA et l’auto remédiation.
J’aime aussi le fait que les agents soient visibles et configurables. L’agent d’alerte peut être raccordé à un modèle précis. L’interface montre le modèle principal, le nombre d’utilisations et le statut. Pour de l’exploitation, c’est plus rassurant qu’une boîte noire qui envoie tout à un endpoint magique.
Autre point positif : le produit prend au sérieux les modèles OpenAI compatibles. J’ai pu brancher un proxy local au lieu d’une clé externe réelle. Pour une équipe qui veut tester avec OpenRouter, vLLM, LM Studio ou un proxy interne, c’est indispensable.
Enfin, le backend a un vrai endpoint de santé. Cela paraît basique, mais pour une console d’ops, c’est vital. On peut superviser le superviseur.
Les limites de ITOps Agent Platform
La limite la plus importante : mon test prouve l’analyse IA et la console web, pas une boucle complète de réparation sur une vraie machine de production. Pour valider ce niveau, il faudrait connecter un serveur SSH jetable, un Prometheus de test et une règle de remédiation complète avec approbation.
Deuxième limite : l’installation Docker est la voie recommandée, mais elle dépend de Docker. En source, ça marche, mais il faut savoir diagnostiquer les problèmes Node, SQLite et native modules. Ce n’est pas encore un simple outil que je donnerais à une petite équipe sans profil DevOps.
Troisième limite : les dépendances npm méritent un audit. Le projet manipule potentiellement des secrets, des clés SSH, des commandes serveur et des workflows de remédiation. Dans ce contexte, des alertes critiques dans l’arbre de dépendances ne doivent pas rester un détail.
Enfin, l’interface est riche, presque trop. Pour un administrateur habitué à Grafana et Ansible, il faudra du temps pour comprendre où se trouve la bonne abstraction : agent, workflow, script, politique de remédiation, exécution ou analyse.
Est-ce que ITOps Agent Platform marche vraiment ?
Oui, pour le périmètre que j’ai testé. Le produit démarre depuis les sources, initialise sa base, expose son interface, accepte un modèle OpenAI compatible, teste la connexion au modèle et exécute un agent sur une alerte réaliste.
Non, je ne dirais pas que la promesse de réparation automatique fermée est entièrement validée par ce test. J’ai obtenu une analyse exploitable, pas une correction appliquée sur un serveur réel. C’est déjà utile, mais ce n’est pas la même chose qu’un self healing sûr et auditable.
Le bon positionnement aujourd’hui : plateforme de labo ou de pré production pour construire des scénarios d’exploitation assistée par IA.
Faut-il adopter ITOps Agent Platform ?
Mon verdict : essayer, mais ne pas adopter directement en production.
Pour une équipe DevOps curieuse, c’est un bon terrain de jeu. Vous pourrez brancher vos modèles, créer des agents spécialisés et tester des workflows d’alerte. Pour une équipe SRE mature, le projet peut servir de prototype afin de comparer une approche multi agents à des runbooks Ansible ou Rundeck.
Pour une production critique, je demanderais d’abord : audit dépendances, durcissement des secrets, tests d’exécution SSH sur cibles jetables, règles d’approbation obligatoires, journalisation vérifiée et scénarios de rollback.
FAQ
ITOps Agent Platform remplace-t-il Prometheus ou Zabbix ?
Non. Il se place plutôt après eux, comme couche d’analyse, d’orchestration et de remédiation. Prometheus ou Zabbix restent les sources d’alertes.
Peut-on utiliser ITOps Agent Platform sans clé OpenAI officielle ?
Oui, si vous avez un endpoint OpenAI compatible. Dans mon test, un proxy local compatible a suffi pour créer un modèle, tester la connexion et exécuter un agent.
ITOps Agent Platform est-il prêt pour la production ?
Pas tel quel selon mon test. Il mérite un essai sérieux en labo, puis un audit sécurité et des scénarios de remédiation contrôlés avant de toucher à des serveurs sensibles.