Un rapport ops mensuel plutôt que trois agents à lancer à la main

domain-expiry-check, check-deps et project-health fonctionnent tous les trois très bien pris séparément. Le problème n'a jamais été leur fiabilité, c'était de me souvenir de les lancer, les trois, régulièrement, sur l'ensemble de mes projets. En pratique, je lançais check-deps quand j'y pensais, domain-expiry-check encore plus rarement, et project-health surtout avant une démo. Trois agents fiables, zéro habitude.

Fusionner sans dupliquer la logique#

La tentation facile aurait été d'écrire un agent qui appelle les trois skills existantes l'une après l'autre. Ça marche, mais ça a un coût concret : domain-expiry-check et project-health interrogent chacun list_projects sur l'API Vercel, plafonnée à 50 résultats sans curseur de pagination exposé. Les enchaîner sans réfléchir double un appel déjà limité, pour récupérer deux fois la même réponse.

monthly-ops-report fait l'appel une seule fois et réutilise la réponse pour les deux besoins : les domaines personnalisés d'un côté, le statut de déploiement de l'autre. Le reste, l'audit npm et l'activité git, garde exactement la même logique que dans les skills sources, juste rassemblé dans un seul passage plutôt que trois invocations séparées.

Un seul classement, pas trois listes côte à côte#

Le vrai choix de conception n'est pas technique, c'est éditorial. Trois rapports séparés répondent chacun à sa propre question : quels domaines expirent, quelles dépendances sont vulnérables, quel déploiement est cassé. Mais avant de montrer un projet, la question que je me pose n'est jamais découpée par axe, c'est une seule question : qu'est-ce qui cloche le plus urgemment, tous sujets confondus ?

monthly-ops-report répond à celle-là. Un domaine qui expire dans 40 jours, une vulnérabilité npm critique et un déploiement de production cassé atterrissent dans la même catégorie "critique", peu importe l'axe d'où ils viennent. Ce qui suit, "à surveiller", "silencieux", "sain", "non vérifiable", mélange les trois sources de la même façon. Le rapport ne dit jamais "voici l'état des domaines, voici l'état des dépendances" : il dit "voici ce qui compte le plus, dans l'ordre".

Ce qu'il ne remplace pas#

Ce rapport donne une vue d'ensemble rapide, pas le détail exhaustif de chaque skill source. Si check-deps remonte des vulnérabilités critiques sur un projet, le réflexe reste de relancer check-deps sur ce projet précis pour voir le détail CVE par CVE. Le rapport mensuel sert à repérer qu'il faut creuser, pas à remplacer l'outil qui creuse.

La cadence vient après, pas avant#

Même règle que j'applique depuis l'article sur les agents planifiés : aucun agent planifié ne commence planifié. monthly-ops-report tournera d'abord manuellement, invoqué à la demande, le temps de vérifier que le classement priorisé correspond vraiment à ce que je jugerais urgent moi-même en le lisant. La bascule vers une exécution mensuelle sans supervision, via une boucle ou un agent planifié, ne se fait qu'une fois cette confiance acquise, jamais avant.

Ce que ça généralise#

Le problème que cet agent résout n'était pas un problème de capacité, chaque skill source faisait déjà son travail correctement. C'était un problème de friction : trois commandes à retenir, trois moments différents pour y penser, et dans les faits, un oubli systématique d'au moins une des trois. Fusionner n'a rien changé aux vérifications elles-mêmes, ça a changé le nombre de fois où je choisis réellement de les faire.

La leçon générale se retourne facilement contre elle-même si on l'applique trop tôt : fusionner trois outils en un seul n'a de sens qu'une fois que chacun des trois a fait ses preuves séparément. Construire d'emblée un agent unique qui fait tout aurait mélangé des bugs de trois origines différentes dans un seul endroit impossible à déboguer proprement.