La gestion de vos dépôts, notée en un seul endroit.

Santé Git vérifie la gestion de chaque dépôt, pas son contenu : la branche par défaut est-elle protégée, les merge requests approuvées, les commits portent-ils une clé de ticket, la sécurité est-elle dans le pipeline, les fichiers indispensables sont-ils là ? 29 règles et un score pondéré, sur GitHub, GitLab, Bitbucket et Azure DevOps.

Nous contacter Planifier une démo

Écrans d'une installation en fonctionnement

Six groupes, 29 règles

Chaque règle répond à une question fermée sur la gestion du dépôt et porte une gravité et un poids.

5 règles

Protection des branches

Branche par défaut protégée, pas de push direct ni forcé, branches de release et tags protégés.

6 règles

Règles de merge request

Approbation requise, nombre minimal d'approbations, pas d'auto-approbation, discussions résolues et pipeline vert avant la fusion, branche source supprimée ensuite.

5 règles

Traçabilité

Commits et titres de MR portent une clé de ticket, les noms de branche suivent un modèle et un outil de suivi est connecté.

7 règles

Sécurité en CI

SAST, détection de secrets, analyse des dépendances et des conteneurs, SBOM et SonarQube avec rapports de MR - repérés dans le pipeline, modèles inclus compris.

5 règles

Hygiène du dépôt

CODEOWNERS, un lockfile versionné, des modèles de merge request et de ticket, et aucun fichier secret commité (repéré par son nom ; le contenu n'est jamais lu). README, .gitignore et SECURITY.md sont vérifiés par le module Conformité.

1 règles

AppArch lui-même

Un collecteur a transmis un rapport dans les 30 derniers jours : les autres scores sont donc à jour.

Inconnu n'est pas zéro

Une règle à laquelle la plateforme ou le jeton ne peut pas répondre est marquée ignorée et sort du score. Une connexion au jeton expiré affiche « 0 sur 2 notables », jamais « 29 échecs ». De même pour un pipeline illisible en entier : un include illisible signifie ignoré, pas échoué.

Aucune inscription, rien à lancer à la main

Tout projet avec une connexion Git participe dès son ajout.

01

Ajouter un projet

La première analyse est mise en file dès la création du projet.
02

Les analyses restent à jour

Les analyses planifiées revérifient chaque dépôt : un réglage modifié la semaine dernière apparaît sans que personne ne le demande.
03

Corriger et suivre le score

Chaque règle en échec dit ce qu'elle a trouvé ; le score du projet figure sur la fiche santé à côté des autres scores.

Ce qui peut être vérifié sur chaque plateforme

Toutes les plateformes n'exposent pas chaque réglage via leur API. Quand l'une ne peut pas répondre, la règle est ignorée et sort du score ; elle ne compte jamais comme un échec.

	GitLab	GitHub	Bitbucket	Azure DevOps
Branches par défaut et de release protégées
Règles de fusion : approbations, pas d'auto-approbation, pipeline vert, fils résolus			ignorée	ignorée
Pas de force push ni de push direct sur la branche par défaut			ignorée	ignorée
Branche source supprimée après fusion			ignorée	ignorée
Tags protégés, clé de ticket imposée par les règles de branche		ignorée	ignorée	ignorée
Clés de ticket dans commits et titres de MR, nommage des branches
CODEOWNERS, lockfile, modèles, aucun secret commité			en partie	en partie
Outils de sécurité en CI : SAST, secrets, dépendances, conteneurs, SBOM, SonarQube
Collector actif, outil de suivi connecté

Les règles qui vérifient plusieurs éléments donnent un crédit partiel : une branche non protégée sur sept ne coûte pas autant que sept.

Toutes les merge requests de tous les fournisseurs, dans une liste

Santé Git rassemble aussi les merge requests de l'espace de travail, quelle que soit leur plateforme.

Filtrer par état, projet, auteur et branche cible, ou chercher
Un badge relie chaque MR revue à son rapport ArchPilot
Le filtre « plus long que d'habitude » d'Archito montre ce qui bloque

Questions sur Santé Git

Quelles plateformes sont couvertes ?

GitHub, GitLab (gitlab.com ou auto-hébergé), Bitbucket Cloud et Azure DevOps. Une règle à laquelle une plateforme ne peut répondre - Bitbucket et Azure DevOps n'ont pas de réglage de suppression de la branche source pour tout le dépôt, par exemple - est ignorée, jamais en échec.

Lit-il notre code ?

Non. Il lit les réglages du dépôt, la protection des branches et des tags, les derniers commits et merge requests, la configuration CI et l'arborescence. Les fichiers secrets sont repérés par leur nom ; leur contenu n'est jamais lu.

De quelles permissions le jeton a-t-il besoin ?

L'accès en lecture couvre la plupart des règles. Quelques réglages ne sont visibles qu'avec un jeton administrateur - la suppression de branche après fusion sur GitHub, par exemple ; sans lui, la règle est ignorée.

Santé Git modifie-t-il nos autres scores ?

Non. Il a son propre score, affiché à côté de ceux d'ArchScan, d'ArchSecurity et de Conformité sur la fiche santé de chaque projet.