Plateformes Git
Dépôts, merge requests et membres viennent d'ici. Connexion par jeton d'accès ou application OAuth ; GitLab auto-hébergé fonctionne aussi.
Revue d'architecture à chaque pull request, sur vos propres serveurs.
AppArch lit la structure de votre base de code - couches, dépendances, contrats - et commente la pull request dès son ouverture. Il s'exécute dans votre CI et sur votre réseau. Rien n'en sort.
- Installé sur site
- 9 langages
- GitLab, GitHub, Bitbucket, Azure DevOps
9langages: langages : .NET, Java, Python, Go, TypeScript, Ruby, PHP, Kotlin, Swift
1000+règles: règles au catalogue, chacune documentée
4plateformes Git: plateformes Git
5modules: modules sur un même graphe de code
<2 minpar revue: par revue : moins de 2 minutes, mesuré sur un dépôt de 5 Go
4référentiels de sécurité: référentiels de sécurité : OWASP, PCI DSS, STIG, CASA
Cinq modules, une seule lecture de votre code
Chaque module répond à une question différente sur le même dépôt. Activez ceux dont vous avez besoin ; ils partagent le catalogue de règles et le graphe de dépendances.
ArchPilot
Commentaires de revue sur la pull request
- Commentaires en ligne avec le code de règle et un lien vers sa documentation
- Un commentaire de synthèse par merge request : nouveaux, ouverts, résolus
ArchScan
Un rapport complet sur toute la base de code
- Chaque constat cite les lignes en cause, pas seulement un nom de fichier
- Une carte de dépendances interactive des projets et paquets
ArchSecurity
Analyse de sécurité statique rapportée aux référentiels des auditeurs
- Un rapport par référentiel, prêt pour l'audit
- Dépendances vulnérables vérifiées contre une base d'avis hors ligne
Conformité
Contrôles de politique avec score et piste d'audit
- Règles activées par projet, par espace de travail ou pour toute l'installation
- Analyses planifiées, pour que le score reste à jour sans que personne n'y pense
Git Health
29 contrôles sur la gestion du dépôt
- Protection des branches, règles de MR, sécurité en CI
- Les constats portent une valeur, pas seulement réussi ou échoué
Par où commencer ?
La plupart des équipes commencent par ArchPilot : le premier commentaire arrive dès la prochaine pull request.
Comment un constat arrive dans votre pull request
Trois étapes, aucun agent sur le poste du développeur, rien qui appelle l'extérieur.
- 01
Enregistrez le dépôt
Connectez un identifiant Git dans le panneau et choisissez le dépôt. AppArch émet un jeton de projet.
- 02
Ajoutez un job à votre pipeline
Une image conteneur par langage s'exécute comme job CI sur le code extrait. Elle récupère les règles, analyse sur place et n'envoie que les résultats.
- 03
Lisez le commentaire, ouvrez le rapport
L'ingénieur voit le constat sur la pull request ; l'équipe voit le score, la tendance et les constats dans le panneau.
Les règles se gèrent dans le panneau, pas dans un fichier
Chaque règle du catalogue a un code, un nom, une description et une page de documentation. Désactivez une règle pour toute l'installation, un espace de travail ou un projet ; le réglage le plus précis l'emporte.
- Le seuil qui fait échouer un pipeline est un réglage, pas une modification de code.
- Le périmètre d'analyse - quels dossiers comptent - se règle au même endroit.
- Chaque règle a sa propre page de documentation sur docs.apparch.io.
Conçu pour fonctionner dans votre réseau
Il n'existe pas de version hébergée. AppArch s'installe sur un hôte que vous contrôlez, et le code qu'il lit ne quitte jamais votre CI.
Installation sur un seul hôte
Docker Compose avec PostgreSQL et Redis. Un assistant crée le premier administrateur ; les mises à niveau appliquent leurs propres migrations.
Connexion avec votre annuaire
Connexion LDAP et Active Directory, authentification à deux facteurs, invitation par domaine. Pas de connexion sociale.
Licence signée, hors ligne si besoin
La licence est un fichier signé que l'installation vérifie localement. Les sites isolés tirent les images d'un registre privé et n'appellent jamais l'extérieur.
Aucune donnée d'usage ne sort
Le seul appel sortant est la vérification de mise à jour, facultative et désactivable. Tout le reste reste sur votre hôte.
À quoi il se connecte
Les plateformes Git apportent les dépôts et les merge requests ; le reste ajoute autour les déploiements, incidents, tickets et l'IA.
Pipelines CI
L'analyseur tourne comme un job dans votre propre pipeline : des extraits prêts pour quatre fournisseurs, un simple docker run pour le reste.
Déploiement
Quelle version tourne dans quel environnement est inscrit dans le catalogue de services.
Observabilité
Avec Dynatrace, New Relic ou Percona PMM connecté, les incidents remontent, et les deux métriques DORA vides, taux d'échec des changements et temps de rétablissement, se remplissent de données réelles. Percona PMM ajoute aussi les temps de requête de la base.
Qualité et tests
Les mesures et constats SonarQube côtoient ceux d'AppArch ; les résumés de tests JMeter arrivent sur la page des tests de performance du projet.
IA
L'opérateur de l'installation connecte un fournisseur ; les requêtes partent de ce compte et rien ne transite par AppArch.
Suivi des tickets
Les constats sont créés comme tickets sur le tableau que votre équipe utilise déjà. Le mappage de projet se configure par espace de travail.
Connexion et notifications
Connexion avec le compte LDAP ou Active Directory ; les notifications partent par e-mail via votre propre serveur SMTP. Les canaux Slack et Teams arrivent.
À quoi sert un outil de revue d'architecture ?
Une base de code est faite de centaines de petites décisions qui, prises une à une, semblent justes : quelle couche appelle laquelle, quand un contrat de service a été rompu, dans quelle modification un contrôle de sécurité a disparu. La revue de code voit ces décisions mais s'use avec le temps ; personne n'écrit le même avertissement à la main dans chaque pull request.
Un outil de revue d'architecture transforme ces décisions en règles et les applique automatiquement à chaque modification. Le développeur voit le constat dans sa propre pull request, le responsable d'équipe suit la tendance dans le panneau, et l'équipe sécurité obtient le rapport de conformité à partir de la même analyse.
Ce qui le distingue d'un linter ou d'une plateforme de qualité de code
Un linter examine un fichier à la fois. AppArch lit le graphe de dépendances de tout le dépôt ; il peut donc signaler qu'un projet de présentation référence l'infrastructure ou que deux modules dépendent l'un de l'autre. Les constats des analyseurs externes apparaissent dans le même panneau, étiquetés avec leur source.
Que regarder pour choisir
- Le code quitte-t-il votre réseau ? Un outil qui tourne sur site garde le code dans votre propre réseau.
- Qui détient les règles ? Gérer les règles dans un panneau plutôt que dans un fichier garde toute l'équipe cohérente.
- Écrit-il dans la pull request ? Un rapport n'est pas lu ; un commentaire en ligne, si.
Pour plus de détails, consultez les pages ArchPilot, On-premise & air-gap et catalogue de règles.
Questions fréquentes
En quoi est-ce différent d'un linter ou de SonarQube ?
Un linter regarde un fichier. AppArch lit le graphe de dépendances de tout le dépôt, et peut donc dire qu'un projet de présentation référence l'infrastructure, ou que deux modules dépendent l'un de l'autre. Les constats SonarQube peuvent être reflétés dans ArchSecurity à côté de ceux d'AppArch, étiquetés par source.
Quels langages sont pris en charge ?
.NET, Java, Python, Go, TypeScript et JavaScript (dont React, React Native et Node.js), Ruby, Kotlin, Swift et PHP. Chacun a sa propre image d'analyse et sa propre partie du catalogue de règles.
Notre code quitte-t-il notre réseau ?
Non. L'analyseur s'exécute comme job dans votre propre CI, sur le code extrait, et n'envoie que les constats au serveur AppArch - qui est aussi le vôtre. Aucun service hébergé sur le chemin.
Et les faux positifs ?
Désactivez la règle pour le projet, l'espace de travail ou toute l'installation, ou réduisez le périmètre d'analyse pour ignorer le dossier. Les constats peuvent aussi être acquittés dans le panneau, et la sévérité d'une règle abaissée pour qu'elle ne fasse plus échouer le pipeline.
Comment est-ce licencié ?
Par installation, avec un fichier de licence signé qui fixe les utilisateurs et les projets ; tous les modules sont inclus. Pas de facturation à l'analyse, pas d'offre hébergée. Contactez-nous, nous le dimensionnerons ensemble.
Combien de temps prend l'installation ?
Un seul hôte avec Docker : tirez les images, lancez le fichier compose, suivez l'assistant. Enregistrer le premier dépôt et ajouter le job CI tient généralement dans le même après-midi.
Voyez-le sur votre propre code
Réservez une démo de trente minutes. Nous parcourons le panneau sur un dépôt réel et répondons aux questions de votre équipe.