Zone d'administration

La zone Administration (/management) est la surface propre de l’opérateur. Elle a sa propre connexion, séparée des comptes produit - un compte opérateur ne peut pas ouvrir les pages produit, et inversement.

Vue d’ensemble

La page d’accueil montre ce que l’installation est et ce qu’elle fait : effectifs (utilisateurs/espaces/projets), cartes d’état par module (ArchPilot, ArchScan, Code Health) derrière un filtre d’espace de travail facultatif, graphiques de répartition, jauge de rythme de travail, activité des 28 derniers jours et, si configurée, la vérification de mise à jour.

Espaces de travail

Chaque espace de travail de l’installation, avec une page de détail par locataire :

les membres (les comptes qui se connectent via LDAP sont badgés - leur mot de passe vit dans l’annuaire),
les projets (un projet sans identifiant est signalé : il explique un dépôt qui n’analyse jamais),
les invitations en attente avec leur échéance,
un interrupteur d’invitations - fermé, l’action d’inviter disparaît pour les membres et l’API refuse l’appel, quel qu’en soit l’auteur. Les admins de l’espace ne peuvent pas le lever.
Une carte Réinitialiser les données de module : choisissez les modules (ArchScan, ArchPilot, ArchSecurity, Conformité, Git Health, analytique d’ingénierie, historique de l’assistant) et leurs résultats pour cet espace sont supprimés physiquement - exécutions, analyses, constats et faits. Règles, intégrations, identifiants et membres restent ; la prochaine analyse ou synchronisation repart de zéro. Aucun retour en arrière, d’où la confirmation préalable.

Les exécutions ArchScan et les revues ArchPilot des écrans de modules de l’espace portent un bouton Supprimer dans le même but : une exécution d’essai qui ne doit pas compter est retirée avec ses constats, définitivement.

Deux pages supplémentaires dépendent de la fiche du workspace :

Configuration - la moitié de la configuration d’un locataire que seuls ses propres membres voyaient : les identifiants avec lesquels il atteint un fournisseur Git (les siens et ceux partagés par l’installation, chacun avec les quatre derniers caractères et le nombre de projets qui l’utilisent), ce à quoi il est connecté (Jira, Trello, Sonar, Slack, Teams, JMeter, Argo CD, Kubernetes, Dynatrace, New Relic), ses planifications d’analyse, ses rôles personnalisés avec les droits accordés et ses groupes de projets. En lecture seule, et aucun secret n’y est lisible.
Détail d’un projet - cliquez sur le nom du projet : branche par défaut, groupe, identifiant et son expiration, les quatre derniers caractères du jeton runner et son ancienneté, si un secret de webhook est défini, les motifs d’inclusion et d’exclusion de la portée d’analyse, les approches d’architecture, les exceptions de règles, le suivi des versions et qui a enregistré le projet. Le jeton et le secret de webhook sont stockés hachés et ne sont pas lisibles.

Un workspace supprimé peut être restauré depuis la liste. Les lignes n’ont jamais été retirées : il revient avec ses projets et son historique.

Écrans de modules

Chaque module a un écran à l’échelle de l’installation, et la plupart ouvrent un espace de travail exactement comme ses membres le voient - mêmes tableaux de bord, mêmes constats, mêmes rapports, en lecture seule là où l’action appartient au locataire (exports, synchronisations, clôture de commentaires).

ArchScan - tableau de bord du parc, plongée par espace vers les exécutions et rapports complets ; Code Health et Dépendances vivent sur sa barre d’onglets avec le même filtre facultatif.
ArchPilot - adoption et issue (réussi / attention / échoué), les règles les plus déclenchées et la fréquence à laquelle leurs commentaires sont suivis d’effet, listes de MR examinées par espace avec le détail des constats.
ArchSecurity - répartition des sévérités, tableau de bord sécurité et rapports par référentiel (OWASP, PCI DSS, DISA STIG, CASA ASVS) par espace, y compris les constats ouverts miroités depuis GitLab/SonarQube - comptés à côté des nôtres, jamais fusionnés.
Conformité, Git Health, Catalogue de services - équivalents à l’échelle de l’installation des écrans locataires, tous restreignables par espace et projet.

Partout, jamais analysé est signalé comme inconnu - ni sain, ni zéro.

Sur les écrans Conformité et Git Health, l’opérateur peut aussi mettre en file une analyse pour un projet au nom du workspace. L’exécution est enregistrée comme déclenchée par operator et attribuée à aucun utilisateur du locataire, pour qu’une action de support ne ressemble jamais à une action du client.

Paramètres

Un écran à onglets : Licence (avec les limites accordées), E-mail (SMTP/Postmark, avec envoi de test), E-mails de rapport, Assistant IA (voir Archito, l’assistant), Inscription & invitations - l’interrupteur d’auto-inscription, la liste des domaines d’e-mail invitables et l’interrupteur deux facteurs de l’installation -, Tableau de bord, Modules (éteindre un module arrête aussi ses jobs planifiés), LDAP, Turnstile, Langues et Analytics. Lorsque la licence expire, l’installation continue de fonctionner pendant un délai de grâce de 14 jours ; ensuite, l’installation s’arrête jusqu’à l’installation d’une nouvelle licence - voir Rester sous licence pour ce que cela signifie et ce qui peut encore l’arrêter.

L’onglet Licence affiche aussi le code d’installation. Une licence fonctionne sur une seule installation : la première installation qui la récupère en ligne la lie à elle-même, et une autre installation qui demande la même licence est refusée. Une installation isolée envoie ce code à AppArch et reçoit un fichier .lic qui ne fonctionne que sur cette installation. Plusieurs pods partageant une même base de données comptent comme une seule installation. Pour migrer vers un nouveau serveur, demandez à AppArch de libérer la licence, puis récupérez-la à nouveau depuis le nouveau serveur - voir Une licence, une installation.

Zone de danger - réinitialisation d’usine

Paramètres > Zone de danger ramène l’installation au premier démarrage : chaque espace, membre, invitation, compte utilisateur, identifiant Git (partagés compris), projet, intégration, analyse, constat et rapport est supprimé et les compteurs d’identité repartent de zéro. Les comptes administrateurs, la licence, les identifiants d’installation, les paramètres, les traductions et les catalogues de règles restent, l’assistant d’installation ne se relance donc pas - l’application n’a simplement plus d’utilisateurs ni d’espaces. Pas de retour possible ; faites d’abord une sauvegarde de la base (docker compose exec postgres pg_dump ...).

La réinitialisation est volontairement difficile à déclencher :

Mot de passe - seul un administrateur détenant toutes les permissions peut la lancer, et doit ressaisir son mot de passe.
Code par e-mail - un code à six chiffres est envoyé à l’adresse de cet administrateur (valable 15 minutes, cinq essais). L’envoi d’e-mails doit être configuré ; il n’existe aucun autre moyen de confirmer.
Confirmation saisie - le nom du client sous licence, exactement tel qu’affiché.
Fenêtre de dix minutes - l’effacement est planifié, chaque administrateur actif reçoit un e-mail avec un lien, et n’importe lequel peut annuler jusqu’à la fermeture de la fenêtre. Ensuite le job démarre sous trente secondes et ne peut plus être arrêté.

Chaque demande est journalisée dans la base d’administration : qui l’a lancée, depuis quelle adresse, et le nombre de lignes supprimées par table. Les administrateurs reçoivent un dernier e-mail avec les totaux. Un interrupteur optionnel supprime aussi la licence - uniquement pour céder l’installation à un autre client.

Exploitation

Mises à jour - version installée face au registre de l’éditeur, par composant, avec un bouton de vérification immédiate. La vérification passe par la passerelle de l’éditeur avec les identifiants d’installation ; les installations isolées la désactivent avec UpdateCheck:Enabled=false.
Avis de sécurité - les données de vulnérabilités auxquelles chaque dépendance analysée est confrontée, par registre, et l’import OSV qui les met à jour. Voir ci-dessous.
Constats - ce que l’installation a remarqué sur elle-même : un job qui a levé une exception, un projet dont la synchronisation échoue sans cesse, un e-mail à bout de tentatives, une ligne refusée par la base. Une ligne par problème avec sa fréquence et la dernière erreur ; elle se ferme seule quand le sujet réussit à nouveau. Marquer comme vu, fermer à la main ou couper un type pour soi seulement. Les constats ouverts s’affichent en badge dans la barre latérale et en bandeau sur l’accueil.
Jobs - chaque job planifié avec un bouton d’exécution immédiate.
Capacité (sa propre page sous Système) - charge mesurée des jobs (durée moyenne de chaque job rapportée à son intervalle, sommée) face aux threads d’un pod Api, les pods vivants de la table de cluster Quartz avec leur CPU et leur mémoire réels, la charge par groupe de modules, les jobs les plus lourds avec filtrage par catégorie et tri par colonne, et une recommandation : un pod porte la charge mais deux sont conseillés pour des redémarrages sans coupure, ou N pods quand la charge doublée dépasse un pod. Apparaît après sept jours d’historique.
Santé du système - sondes PostgreSQL et Redis en direct (jamais mises en cache) plus l’état du planificateur. Pour les sondes d’orchestrateur, utilisez plutôt les points non authentifiés /health/live et /health/ready - voir installation on-prem.
Intégrations - l’inventaire de tout ce à quoi l’installation parle, par espace, sans secrets.
Utilisateurs, invitations, administrateurs - la gestion des comptes des deux plans.

Avis de sécurité

Chaque exécution ArchScan remonte les dépendances déclarées par le dépôt. L’Api compare cette liste au catalogue d’avis propre à l’installation et ouvre un constat pour tout paquet dont la version installée tombe dans une fenêtre vulnérable publiée (CWE-1104, rattaché à OWASP A06 et aux contrôles PCI, STIG et CASA). La comparaison a lieu ici plutôt que dans le runner : un job CI sur le réseau du client ne peut joindre aucun service CVE, et une image de collector figée il y a un an porterait des données d’il y a un an.

Le produit fournit une base curatée pour les huit registres que lisent les collectors : NuGet, npm, PyPI, Maven (Java et Kotlin), Go, RubyGems, Packagist et SwiftPM. Les données de vulnérabilités vieillissent en quelques semaines : rafraîchissez-les dans Administration → Avis de sécurité. Sur une machine connectée, téléchargez l’export du registre voulu depuis osv.dev (osv-vulnerabilities/<registre>/all.zip), réunissez les enregistrements dans un seul tableau JSON et téléversez le fichier. L’analyse suivante s’y compare, sans reconstruction d’image ni appel sortant.

Un import ajoute et met à jour ; il ne supprime jamais une ligne et ne réactive jamais un avis qu’un opérateur a désactivé après un faux positif. L’écran montre aussi les registres sans aucun avis, ce qui revient à un langage dont personne ne vérifie les dépendances.

Connexion administrateur et verrouillage

Chaque tentative de connexion à l’administration est enregistrée - qui, depuis quelle adresse, avec quel navigateur et pourquoi elle a échoué (mot de passe incorrect, e-mail inconnu, compte inactif, compte verrouillé). La trace se trouve dans Audit > Connexions.

Après cinq échecs, un compte est verrouillé quinze minutes. Le verrou porte sur le compte, pas sur l’adresse : chaque connexion atteint l’API via le pod d’interface, un verrou par adresse ne compterait qu’une machine. Un compte verrouillé est signalé dans la liste des administrateurs et tout administrateur disposant du droit Administrateurs peut le déverrouiller sans attendre.

Chaque jeton d’opérateur appartient désormais à une session, et Mes sessions (depuis l’écran des administrateurs) les liste : appareil, adresse, début et dernière utilisation, celle que vous regardez étant signalée. Mettre fin à une session déconnecte ce navigateur à sa requête suivante, et elle ne peut plus être renouvelée ensuite : « déconnecter cet ordinateur » le fait vraiment, au lieu de durer jusqu’à l’expiration fortuite du jeton. Terminer toutes les autres sessions nettoie le reste en une action.

Un administrateur disposant du droit Administrateurs peut aussi déconnecter partout un collègue sans toucher à son compte. Auparavant il fallait le désactiver, ce qui lui retire l’accès jusqu’à ce que quelqu’un pense à le rétablir.

Supprimer un administrateur

Supprimer l’administrateur dans la liste retire le compte : il disparaît de la liste, ne peut plus se connecter, ses sessions en cours s’arrêtent immédiatement et son adresse e-mail redevient libre pour son remplaçant.

La ligne en base survit, et c’est délibéré. La piste d’audit, l’historique de connexion et chaque référence « modifié par » nomment leur acteur par l’identifiant de ce compte, sans clé étrangère derrière. Supprimer la ligne les réduirait toutes à « quelqu’un » : la piste survivrait au compte mais aurait oublié qui l’occupait. Le compte est donc vidé et masqué partout où il pourrait encore servir.

Vous ne pouvez pas supprimer votre propre compte : une requête qui détruit ses propres identifiants en cours de route est une façon déroutante d’écrire « se déconnecter », et un clic malheureux vous exclurait de l’espace. Pour votre propre compte, demandez à un collègue.

Ce que chaque droit protège

Les droits d’un administrateur déterminent ce qu’il peut faire, pas seulement ce qu’il voit - l’API refuse l’appel dans tous les cas :

Licence - installer et remplacer la licence.
Utilisateurs - suspendre, réactiver et supprimer des comptes, réinitialiser des mots de passe.
Administrateurs - créer des administrateurs, modifier les droits, déverrouiller.
Paramètres - tous les onglets de paramètres, les paramètres d’intégration et les identifiants partagés.
Workspaces - cycle de vie : propriété, appartenance, interrupteurs d’invitation, suppression et restauration.
Données - suppression physique : purge d’un workspace, suppression d’une exécution ou d’une revue.
Exploitation - suspendre et reprendre les tâches, exports, envoi d’e-mails.

Un administrateur sans un droit ne voit pas le groupe de menu correspondant, et les points de terminaison concernés répondent 403.

Supprimer un utilisateur

La page d’un utilisateur liste les workspaces auxquels il appartient et, s’il n’en possède aucun, une action Supprimer l’utilisateur. Elle retire chaque appartenance, connexion externe, inscription à la double authentification et code de récupération, révoque ses sessions et efface l’identité - l’historique de connexion et la piste d’audit restent, car ils sont le compte rendu de ce qui s’est passé. Une personne qui possède encore un workspace ne peut pas être supprimée : transférez d’abord la propriété, ce qui est une seule action sur la page du workspace.