Guardian

Qu'est-ce que Guardian ?

Guardian est une couche de décision de release pour les changements de code assistés par IA. Au lieu de simplement détecter les problèmes, elle évalue les mises à jour de code risquées ou à forte composante IA par rapport aux politiques et produit une décision de release explicite (pass, pass avec avertissement ou blocage) accompagnée de preuves.

Le produit est conçu pour aider les petites équipes d'ingénierie à standardiser l'approbation du code avant sa mise en production. Guardian applique les mêmes contrôles pilotés par politique sur les workflows desktop, CLI et CI, et inclut un processus d'approbation humaine avec un historique auditable pour les overrides à haut risque.

Fonctionnalités clés

• Couche de décision de release (pas seulement détection) : Génère une décision claire go/no-go pour les changements de code assistés par IA, avec justification, plutôt qu'une simple liste de problèmes.
• Routage des changements IA-intensifs / volumineux : Identifie les pull requests assistés par IA ou inhabituellement volumineux et les oriente vers des parcours de revue plus stricts avant release.
• Application des politiques de votre équipe : Applique les règles d'architecture, de sécurité et de qualité définies comme politique aux changements risqués, en mettant en évidence les violations avec des explications en langage clair.
• Workflow d'approbation humaine avec traçabilité : Pour les flux à haut risque, capture l'approbateur nommé, le propriétaire de l'override et la raison enregistrée dans un historique d'audit.
• Workflow policy-as-code local-first multi-environnements : Garde le policy-as-code dans le repository et supporte un flux desktop + CLI fonctionnant localement si nécessaire.

Comment utiliser Guardian

1. Définissez les politiques de votre équipe (règles d'architecture, de sécurité et de qualité) et stockez-les dans votre repo sous forme de policy-as-code.
2. Utilisez Guardian dans vos workflows desktop/CLI ou CI pour que les changements assistés par IA et volumineux soient évalués de manière cohérente avant release.
3. Examinez les résultats d'application des politiques pour les changements risqués, incluant les explications des violations.
4. Effectuez l'approbation humaine si requise : choisissez le chemin de décision approprié (pass, pass avec avertissement ou blocage), et en cas d'override d'un blocage, fournissez un approbateur/propriétaire nommé et une raison.
5. Fiez-vous à la surface de décision de release pour la réponse finale : utilisez la décision explicite plus les preuves étayées par un audit trail.

Cas d'usage

• Contrôler les gros pull requests assistés par IA : Quand un développeur crée un gros PR avec des outils comme Copilot/Claude/Cursor, Guardian détecte le changement IA-intensif ou volumineux et l'oriente vers une évaluation plus stricte avant release.
• Détecter les dérives architecturales dans le travail généré par IA : Guardian met en évidence les violations architecturales et politiques dans les changements IA-intensifs et explique pourquoi elles sont importantes pour les relecteurs.
• Appliquer les règles de sécurité et de qualité aux gates de release : Les équipes peuvent appliquer les politiques d'architecture, de sécurité et de qualité aux changements risqués pour aligner les décisions de release sur les règles du repository.
• Standardiser le comportement d'approbation multi-outils : Comme la même politique repo est appliquée sur desktop, CLI et CI, les équipes réduisent les variations entre relecteurs et décisions.
• Maintenir des audit trails pour les overrides : Si un élément à haut risque est autorisé malgré un blocage, Guardian enregistre qui a approuvé, qui a overriddé et pourquoi, rendant la décision auditable.

FAQ

• Guardian arrête-t-il les changements dès qu'il trouve des problèmes ? Non. Guardian est une couche de décision de release qui produit une décision de release (pass, pass avec avertissement ou blocage) avec preuves, plutôt que de lister seulement les problèmes.

• Quels types de changements Guardian considère-t-il comme plus risqués ? Il se concentre sur les changements assistés par IA et les pull requests de refactorat inhabituellement volumineux, en les orientant vers des parcours d'évaluation plus stricts.

• Comment Guardian gère-t-il la traçabilité des approbations à haut risque ? Pour les flux à haut risque, il exige un approbateur nommé et un propriétaire d'override, et enregistre la raison dans un historique d'audit.

• Où les politiques sont-elles définies et stockées ? Guardian utilise du policy-as-code stocké dans votre repo, et supporte un flux desktop + CLI fonctionnant localement si nécessaire.

• Comment la décision finale est-elle communiquée ? Guardian répond explicitement à la question du gate de release avec une décision pass, pass avec avertissement ou blocage, étayée par un audit trail.

Alternatives

• Revue de code manuelle avec listes de contrôle internes : Au lieu d’une porte de release pilotée par des politiques qui produit une surface de décision auditable, les équipes s’appuient sur les relecteurs et la documentation pour décider de ce qui peut être déployé.
• Analyse statique ou scanners de sécurité : Ces outils mettent généralement l’accent sur la détection et le signalement des problèmes ; Guardian produit une décision de release de type gouvernance (incluant preuves et historique d’approbation/surcharge) plutôt que seulement « problèmes trouvés ».
• Plateformes générales de politique/conformité pour la livraison logicielle : Les catégories adjacentes incluent les outils qui gèrent les workflows de gouvernance, mais l’accent spécifique de Guardian porte sur la décision pour les changements de code assistés par IA et inhabituellements volumineux avec policy-as-code sur desktop/CLI/CI.
• Revue par agent uniquement (basée sur chat/session) : Si les équipes s’appuient uniquement sur les suggestions de l’agent sans application cohérente de politiques et une surface de décision de release explicite, la qualité des décisions peut varier selon les prompts, modèles et opérateurs — Guardian est conçu pour standardiser le processus de porte de release.