Intégrations Marketplace : les données de vos outils, sur votre architecture
Le mois dernier, j'ai regardé une équipe déboguer un incident de production à travers sept onglets de navigateur. Datadog pour les métriques. GitHub pour l'historique des déploiements. SonarQube pour le quality gate que quelqu'un avait peut-être contourné. ArgoCD pour confirmer que le pod exécutait bien la version qu'ils croyaient. Et quelque part en arrière-plan, leur diagramme d'architecture dans un autre onglet, parfaitement exact, parfaitement statique, parfaitement inutile pour le problème en cours.
Le diagramme leur disait ce que le système était. Il ne pouvait pas leur dire comment il allait.
Ce n'est pas un problème d'outillage. Chacun de ces outils est excellent dans ce qu'il fait. Le problème, c'est le fossé entre eux — le changement de contexte permanent, le modèle mental qu'il faut reconstruire à chaque saut d'un dashboard à l'autre, la question implicite que personne ne pose à voix haute : "Lequel de ces sept outils me montre ce que j'ai vraiment besoin de voir en ce moment ?"
On a construit les Intégrations Marketplace pour combler ce fossé.
L'idée
Le principe est simple : votre diagramme d'architecture est déjà la carte de votre système. C'est là que vous allez pour comprendre ce qui existe, comment les choses se connectent, quels protocoles elles utilisent. Pourquoi ne serait-ce pas aussi l'endroit où vous voyez comment les choses fonctionnent ?
Le Marketplace d'Archyl vous permet de connecter des services externes — Datadog, GitHub, GitLab, Prometheus, SonarQube, ArgoCD, PagerDuty — et d'afficher leurs données sous forme de widgets en temps réel sur vos tableaux de bord de projet. Pas des captures d'écran. Pas des liens. Des données réelles, rafraîchies toutes les 30 secondes, juste à côté de vos diagrammes C4.
Un badge de statut de déploiement à côté du conteneur qu'il déploie. Un compteur de couverture de code lié au service qu'il mesure. Une liste d'alertes qui montre ce qui brûle, dans le contexte de l'architecture qui est en feu.
Ce que vous pouvez connecter
On a lancé avec sept produits, choisis parce qu'ils couvrent la chaîne d'outils que la plupart des équipes utilisent déjà :
Datadog — Santé des monitors, requêtes métriques, alertes actives, dashboards intégrés. Si vous utilisez déjà Datadog pour surveiller votre infrastructure, vous pouvez faire remonter ces mêmes données sur votre espace d'architecture sans dupliquer une seule requête.
GitHub — Statut des workflows, pull requests ouvertes, statistiques de dépôt, alertes Dependabot, secret scanning, code scanning. Les widgets sécurité justifient à eux seuls la mise en place — au lieu de vérifier l'onglet sécurité de chaque dépôt individuellement, vous voyez les résultats contextualisés par rapport à l'architecture.
GitLab — Statut des pipelines, merge requests, statistiques de projet, et la suite complète des scanners de sécurité : analyse de vulnérabilités, SAST, détection de secrets, DAST. Même idée que GitHub, natif dans l'écosystème GitLab.
Prometheus — Requêtes instantanées pour les valeurs métriques actuelles, requêtes sur une plage rendues en graphiques de séries temporelles, et monitoring de la santé des cibles. Si vous avez déjà des requêtes PromQL pour vos métriques clés, vous pouvez les afficher directement sur votre espace d'architecture.
SonarQube — Statut du quality gate, mesures du projet (couverture, bugs, vulnérabilités, dette technique), issues par sévérité, security hotspots et notes de sécurité. Le widget quality gate est particulièrement utile : un badge vert ou rouge par service vous dit instantanément si le code respecte vos standards.
ArgoCD — Santé et statut de synchronisation des applications, inventaires d'applications, listes de ressources Kubernetes et compteurs d'applications avec filtres. Pour les équipes qui tournent sur Kubernetes, ça transforme votre diagramme C4 en dashboard de déploiement.
PagerDuty — Statut des incidents, liste des incidents actifs, astreintes en cours, santé des services et compteurs d'incidents. Pour les équipes qui gèrent la réponse aux incidents, ça met vos alertes opérationnelles dans le contexte de l'architecture qu'elles affectent — plus besoin de jongler entre PagerDuty et votre diagramme système pour comprendre quel service est réellement en feu.
Chaque produit supporte plusieurs types de widgets — compteurs, badges de statut, listes, graphiques de séries temporelles et iframes intégrés — pour choisir la bonne visualisation pour la donnée.
Comment ça marche
Le système a trois couches :
Les connexions vivent au niveau de l'organisation. Un admin crée une connexion en fournissant des identifiants (une clé API, un token, une URL de serveur). Une connexion peut alimenter des widgets à travers tous les projets de l'organisation. Vous pouvez créer plusieurs connexions vers le même produit — par exemple, une pour votre compte Datadog de production et une autre pour le staging.
Les widgets vivent au niveau du projet (ou de l'élément, ou de l'organisation). Vous ajoutez un widget en choisissant une connexion, un type de widget et en configurant la requête. Un widget GitHub "Pull Requests ouvertes" a besoin d'un propriétaire et d'un nom de dépôt. Un widget Prometheus "Requête sur une plage" a besoin d'une expression PromQL et d'une période. Un widget SonarQube "Quality Gate" a besoin d'une clé de projet.
La grille est l'endroit où les widgets vivent visuellement. C'est un layout drag-and-drop de 12 colonnes avec des sections nommées. Vous pouvez créer des sections comme "Monitoring", "Sécurité", "CI/CD", les replier, les réordonner et redimensionner les widgets individuellement. Tout se sauvegarde automatiquement.
La mise en place d'un widget typique prend environ 30 secondes. Choisir la connexion, choisir le type, coller la config, terminé. Le widget commence à récupérer les données immédiatement.
Pourquoi des widgets, pas des dashboards
On aurait pu construire un produit de dashboard traditionnel. Des lignes de graphiques, une barre latérale de filtres, le classique.
On ne l'a pas fait, parce que ça existe déjà. Datadog a des dashboards. Grafana a des dashboards. Vous n'avez pas besoin d'un outil de dashboard supplémentaire. Ce dont vous avez besoin, c'est un moyen de voir les bonnes données dans le bon contexte — et le contexte, c'est votre architecture.
Un dashboard Grafana qui montre les métriques CPU de dix services est utile. Mais il ne vous dit pas lequel de ces services est l'API gateway, lequel est le processeur de paiement, et lequel est le système de notifications. Votre diagramme d'architecture, si. Mettre la métrique CPU sur l'architecture, à côté du conteneur auquel elle appartient, signifie que vous n'avez jamais besoin de faire cette correspondance mentale vous-même.
C'est le même principe derrière tout ce qu'on construit chez Archyl : la documentation d'architecture devrait être l'endroit unique où vous allez pour comprendre un système. Pas seulement sa structure — ses décisions (ADRs), ses spécifications (Contrats API), son historique de déploiement (Releases), et maintenant sa réalité opérationnelle (Intégrations Marketplace).
Sections et organisation
On savait dès le départ qu'un mur plat de widgets ne passerait pas à l'échelle. Quand vous avez quinze widgets sur un projet — certains pour le monitoring, certains pour la sécurité, certains pour le CI/CD — il vous faut de la structure.
Les widgets sont organisés en sections nommées. Vous les créez, les nommez, les réordonnez en glissant leurs en-têtes, et repliez celles dont vous n'avez pas besoin maintenant. Chaque section agit comme un panneau que vous pouvez ouvrir ou fermer.
En mode édition, vous pouvez :
- Glisser les widgets pour les repositionner dans une section
- Déplacer les widgets entre sections
- Redimensionner les widgets d'un badge compact à un graphique pleine largeur
- Glisser les en-têtes de section pour réordonner des groupes entiers
- Créer, renommer et supprimer des sections
La grille se compacte verticalement, donc pas d'espaces vides. Quand vous avez fini d'arranger, cliquez sur "Terminé" et le layout se verrouille.
Portée : Organisation, Projet, Élément
Toutes les données n'appartiennent pas au même niveau.
Les widgets d'organisation sont visibles dans tous les projets. Utilisez-les pour des métriques qui comptent globalement — nombre total de déploiements, statut quality gate SonarQube à l'échelle de l'entreprise, résultats de sécurité GitHub au niveau de l'organisation.
Les widgets de projet apparaissent uniquement dans l'onglet Intégrations d'un projet spécifique. Ce sont les plus courants — dashboards de monitoring, statut CI/CD, métriques de qualité de code pour les services de ce projet.
Les widgets d'élément s'attachent directement à un élément C4. Ouvrez le panneau de détails d'un conteneur et vous voyez ses widgets à côté de ses relations, ADRs et contrats API. C'est la portée la plus puissante : des données opérationnelles contextualisées à l'élément architectural auquel elles appartiennent.
Ce que ça change
Avant les Intégrations Marketplace, comprendre l'état opérationnel d'un système signifiait ouvrir plusieurs outils, croiser les données, et maintenir la correspondance entre "dashboard de monitoring" et "diagramme d'architecture" dans votre tête.
Après : vous ouvrez un espace. L'architecture vous dit ce qui existe. Les widgets vous disent comment ça va. Les releases vous disent ce qui a été livré. Les ADRs vous disent pourquoi c'est construit comme ça. Les contrats API vous disent à quoi ressemblent les interfaces.
Un seul endroit. Un seul contexte. Pas de changement d'onglet.
C'est la vision qu'on construit depuis le premier jour. De la documentation d'architecture qui répond à de vraies questions — pas seulement "c'est quoi ce système ?" mais "est-ce que ce système est en bonne santé ?", "est-ce que ce service est sécurisé ?", "c'était quand le dernier déploiement ?" et "quel est le statut du quality gate de ce code ?"
Les Intégrations Marketplace sont un grand pas vers cette vision. Et on ne fait que commencer — d'autres produits arrivent.
Pour démarrer
- Allez dans Paramètres de l'organisation > Marketplace
- Connectez un produit (vous aurez besoin d'une clé API ou d'un token)
- Ouvrez l'onglet Intégrations de n'importe quel projet
- Cliquez sur Personnaliser, puis Ajouter un widget
- Choisissez une connexion, sélectionnez un type de widget, configurez, c'est fait
Toute la mise en place prend moins de cinq minutes. Vos diagrammes d'architecture ne seront plus jamais les mêmes.
Envie de voir comment d'autres fonctionnalités donnent vie à votre architecture ? Découvrez la Gestion des Releases pour le suivi des déploiements, ou les Contrats API pour lier vos spécifications API au diagramme.