Produit
Archito NouveauApprend de vos merge requests, signale ce qui bloque Intégrations 25
Solutions
Par rôle
Pourquoi AppArch
Ressources
Clients Tarifs Contact
Langue
Nous contacter

Quel service appartient à qui ? Une seule source répond.

Le catalogue de services réunit dans une fiche unique ce qu'est chaque service, qui en est responsable, ses dépendances et ses environnements de déploiement - découverts automatiquement depuis votre code.

Écrans d'une installation en fonctionnement

L'inventaire se construit en trois étapes

Vous ne remplissez pas un tableau vide à la main. AppArch déduit des services candidats depuis vos dépôts connectés et vous les validez.

  1. 01

    Détecter

    Les dépôts connectés sont analysés et des services candidats apparaissent. Vous examinez la liste, puis importez ou écartez.

  2. 02

    Attribuer

    Vous attribuez à chaque service un responsable, un niveau de criticité et un état de cycle de vie. Aucun service ne reste orphelin.

  3. 03

    Relier

    Les dépendances, déploiements, la spécification d'API et les liens de documentation sont ajoutés. La fiche est complète.

Que contient une fiche de service ?

Le texte libre n'est pas un champ. Chaque fiche porte les mêmes champs, ce qui garde l'inventaire consultable et comparable.

kind

Type de service

Service, API, frontend, bibliothèque, worker, infrastructure ou autre. Le moyen le plus rapide de filtrer l'inventaire.

lifecycle

Cycle de vie

Expérimental, production, déprécié ou retiré. Cela indique sur quels services on peut compter.

tier

Niveau de criticité

Le tier 1 est critique pour l'activité, une panne est un incident majeur. Le tier 3 concerne l'outillage interne et les essais.

owner

Responsable

Chaque service a un développeur ou un utilisateur comme responsable. La réponse à qui connaît ça figure dans la fiche.

dependencies

Dépendances

L'infrastructure qu'apporte chaque service - PostgreSQL, Redis, Kafka - est déduite des ressources Kubernetes remontées par votre source de déploiement, avec la ressource révélatrice affichée comme preuve.

deployments

Déploiements

Une fois Argo CD, Flux ou Kubernetes connecté, le catalogue montre quelle version tourne où.

api-spec

Spécification d'API

La spécification OpenAPI est rattachée depuis le dépôt, une URL ou manuellement. Titre, version et nombre d'endpoints rejoignent la fiche.

links

Liens

Documentation, runbook, tableau de bord, astreinte, dépôt et liens d'API se trouvent à côté du service.

Gold, Silver, Bronze : ce qui manque à un service

Chaque service est vérifié selon la même liste. Un contrôle qui ne lui correspond pas, comme une spec d'API pour une bibliothèque, est écarté au lieu de compter contre lui.

  1. Gold100%
  2. Silver≥ 75%
  3. Bronze≥ 50%
  4. Aucun niveau< 50%
  • Analysé dans les 30 derniers jourssi un projet est lié
  • Spécification d'APIservices et API
  • Déployésauf bibliothèques
  • Lien d'astreinteTier 1 uniquement

D'où une fiche de service tire ses données

Vous renseignez le responsable et les liens. Le reste est lu selon un planning et reste à jour tout seul.

  • Argo CD · Flux · Kubernetes

    Déploiements

    Toutes les 10 minutes : version par environnement, état de synchro, santé, et les bases, caches et files livrés avec le service.

  • openapi · swagger

    Spécification d'API

    Trouvée dans le dépôt par son nom (racine, docs, api, spec), récupérée depuis une URL ou collée à la main. Rafraîchie chaque heure ; un échec conserve la dernière bonne copie.

  • ArchScan

    Projet lié

    La date et le score de la dernière analyse du projet derrière le service.

  • Renseigné par vous

    Responsable, tier, cycle de vie, liens doc, runbook, tableau de bord et astreinte.

Quand ouvre-t-on vraiment le catalogue ?

Un inventaire n'est pas une fin en soi. Il prouve son utilité dans trois moments.

Première semaine

Un développeur rejoint l'équipe

Combien de services existent, à quoi ils servent, à qui s'adresser. Une liste au lieu d'une semaine d'explications de couloir.

03h00 du matin

Astreinte pendant un incident

Le responsable, le lien du runbook, le niveau de criticité et les dépendances, sur un seul écran. Vous récupérez les minutes perdues à chercher.

Fin de trimestre

Une revue d'architecture

Combien de services expérimentaux ont glissé en production, quel service Tier 1 n'a pas de responsable, lequel n'a jamais atteint le niveau Gold. Les questions reposent sur des données.

Questions fréquentes

Dois-je remplir le catalogue à la main ?
Non. Les services candidats sont déduits automatiquement de vos dépôts connectés et vous les importez depuis la liste des services détectés. L'ajout manuel reste possible.
D'où viennent les informations de déploiement ?
Du module Intégrations. Connectez Argo CD, Flux ou Kubernetes et les déploiements arrivent dans la fiche. Sans connexion, le champ reste vide et la fiche fonctionne quand même.
Que montrent les dépendances du catalogue ?
L'infrastructure livrée avec un service - bases de données, caches, files - lue depuis les ressources Kubernetes remontées par votre source de déploiement. Ce n'est pas un graphe d'appels entre services : qui appelle qui est une information d'exécution qui demande du tracing. La carte d'ArchScan est encore autre chose : elle montre les dépendances dans le code, entre projets et classes.
Quelles formules incluent le catalogue ?
Le catalogue fait partie de toute licence, comme chaque module. Pendant un PoC, vous le voyez d'abord sur vos propres dépôts.
Où nos données sont-elles conservées ?
Une fiche du catalogue contient des métadonnées : nom, type, responsable, liens. Elle réside, comme tout le reste, dans l'installation AppArch sur vos propres serveurs.

Voir dans le produit

Toutes les captures

Constituez votre inventaire en un après-midi

Connectez vos dépôts, validez les services détectés, attribuez les responsables. Le reste reste à jour tout seul.

Abonnez-vous à notre newsletter

Nouveaux modules, notes de version et articles sur l'architecture. Désinscription en un clic, quand vous voulez.