Documentation
README présent et d'au moins 500 caractères, une LICENSE reconnue (pour les dépôts publics), CHANGELOG, CONTRIBUTING, une section de conception dans architecture.md.
Conformité vérifie chaque dépôt selon une checklist de 36 règles : documentation, hygiène du dépôt, sécurité, CI et intégration. Chaque analyse produit un score pondéré et une liste de résultats à remettre à un auditeur.
Écrans d'une installation en fonctionnement
Conformité regarde ce que contient un dépôt et comment il est configuré, pas la logique du code. Chaque règle est une question oui-non avec une sévérité.
README présent et d'au moins 500 caractères, une LICENSE reconnue (pour les dépôts publics), CHANGELOG, CONTRIBUTING, une section de conception dans architecture.md.
.gitignore et .editorconfig, une description et des topics, une branche par défaut main ou master, non archivé ; pour les backends un Dockerfile multi-étapes et un docker-compose local.
Une politique de sécurité, des mises à jour automatiques des dépendances, un .env.example, des conteneurs exécutés sans root, des images de base issues de registres autorisés, NuGet uniquement depuis des flux autorisés.
Un workflow CI existe et lance les tests, un badge de build dans le README, un script lint pour les frontends, Fastlane pour les applis mobiles.
L'identifiant Git du projet est sain, ArchPilot a revu une merge request récemment, l'espace a un canal de notification.
Un frontend n'a pas de Dockerfile à vérifier et une appli mobile pas de robots.txt. Vous choisissez les piles de chaque projet ; les règles universelles et d'intégration s'appliquent toujours.
Chaque résultat est réussi, échoué, ignoré ou en erreur. Seuls réussi et échoué comptent, pondérés par la sévérité ; une règle sans réponse sort du dénominateur au lieu de faire baisser le score.
Pourquoi : une coupure de VPN a un jour affiché 6/100 pour tous les projets. Un serveur Git injoignable ne dit rien du dépôt ; il ne compte donc plus.
À la main, ou par une planification quotidienne ou hebdomadaire pour un groupe ou une liste de projets.
Un worker la prend en quelques secondes ; l'analyse note qui ou quoi l'a déclenchée.
Les fichiers, réglages du dépôt et protections de branche sont lus chez le fournisseur Git ; rien n'est cloné.
Le score rejoint l'historique et la fiche santé du projet, ainsi que l'e-mail récapitulatif si vous y êtes abonné.
Les règles s'activent ou se désactivent à trois niveaux : défaut de l'installation, espace et projet. Le réglage le plus précis l'emporte.
Choisissez la pile de chaque projet, activez les règles voulues, planifiez les analyses ; le score reste à jour sans que personne n'y pense.
Nouveaux modules, notes de version et articles sur l'architecture. Désinscription en un clic, quand vous voulez.