POUR DEVOPSZirconium
Audit & remédiation des findings de sécurité
Les audits de sécurité finissent en fichiers éparpillés qui vieillissent en silence. Zirconium inverse le flux : la base est la source de vérité, les scans l'alimentent, les équipes y suivent la remédiation, et les rapports .md/.pdf deviennent des instantanés générés et figés. Via MCP, vos agents de développement récupèrent les findings ouverts et renvoient leurs corrections avec la référence du commit.
Architecture
Modules
Tableau de bord des findings
Les projets avec leur état, leur score de confiance et les scans en cours. Findings filtrables par sévérité, statut et catégorie ; chaque fiche rassemble description, localisation, recommandation, commentaires et historique complet.
Scans de sécurité par IA
Manuels, planifiés ou déclenchés par webhook. Choisissez la branche et l'agent IA ; le scan normal évite les commits déjà analysés, le re-scan relit le même état, la contre-revue vérifie si les findings existants tiennent toujours. Dépendances analysées, doublons évités.
Exécutions isolées
Chaque exécution a son propre rapport : branche et commit analysés, résultats, durée, agent et modèle utilisés, erreurs. Le scan tourne dans un environnement isolé — l'agent n'obtient ni le jeton du projet ni les identifiants Git.
Agents de dev via MCP
Demandez à un agent « check les soucis du projet X » : il interroge Zirconium pour les findings ouverts, corrige le code, et renvoie la résolution avec une explication et la référence du commit.
Cycle de vie d'un finding
Ouvert → corrigé → régression possible ; accepté (justification obligatoire), ne sera pas corrigé, ou obsolète quand il disparaît au re-scan — jamais supprimé. Le nombre de réouvertures reste visible pour repérer les problèmes récurrents.
Historique & Traçabilité
Tout est conservé, rien n'est écrasé : un journal d'événements pour chaque transition (auteur, commentaire, commit), des révisions de contenu lisibles, des rapports figés dans leur version d'origine, et une corbeille avec restauration.
Organisations & Rôles
Les organisations possèdent les projets et les accès aux dépôts. Membres invités par e-mail (invitations à expiration, usage unique), quatre rôles d'owner à viewer, identifiants Git gérés au niveau de l'organisation — seul le nécessaire sert à chaque scan.
Notifications & Webhooks
Canaux Discord et Telegram, par type d'événement et par projet : nouveaux findings, changements de statut, rapports, déroulement des scans. Les webhooks entrants déclenchent un scan à la mise à jour d'un dépôt ; les envois en échec sont réessayés.
Avant & Après
| Sans Zirconium | Avec Zirconium |
|---|---|
| Des rapports d'audit éparpillés qui vieillissent | La base comme source de vérité, rapports figés générés |
| Aucune idée de ce qui reste ouvert | Findings filtrables par sévérité, statut, catégorie |
| Un rapport mis à jour à la main après un fix — ou pas | L'agent renvoie la correction avec son commit, via MCP |
| Qui a décidé quoi, et quand ? | Chaque transition datée, attribuée, commentée |
| Re-scanner tout le dépôt à chaque commit | Scan normal, re-scan, contre-revue — sans doublons |
| Un finding supprimé disparaît à jamais | Obsolète ou en corbeille — jamais effacé, réouvertures comptées |
Chiffres clés
Envie de voir les apps en action ?
Contactez-nous pour une démonstration des produits — on vous montre tout, en direct.