canary

Vue d’ensemble du skill canary

Le skill canary sert à la surveillance post-déploiement lorsque vous devez vérifier qu’une application en production continue de fonctionner correctement après sa mise en ligne. Il surveille les erreurs de console, les échecs de page et les régressions de performance en production, puis compare le comportement actuel à une base de référence définie avant le déploiement. Si vous cherchez un skill canary qui évalue un risque réel côté utilisateur au lieu de s’appuyer sur une simple invite statique, celui-ci est conçu pour le monitoring après mise en production.

À quoi sert canary

Utilisez canary quand la mission consiste à surveiller un déploiement, détecter des pages cassées ou confirmer qu’une release n’a pas introduit de régression visible. C’est particulièrement pertinent pour les équipes qui veulent utiliser canary pour le monitoring des erreurs de console, des captures d’écran et des échecs au niveau des pages.

En quoi il diffère d’une invite générique

Une invite générique du type « vérifie le site » s’arrête souvent à une revue superficielle. canary est pensé autour d’un workflow de surveillance : exécution après déploiement, observation du comportement réel dans le temps, comparaison à une base de référence et signalement des anomalies. Il est donc bien plus utile quand la vraie question est « la production est-elle saine maintenant ? » plutôt que « cette page a-t-elle l’air correcte à un instant T ? »

Cas d’usage idéal et limites

Ce skill convient aux workflows proches du CI ou aux usages d’exploitation où la confiance après déploiement compte vraiment. Il est moins utile si vous n’avez besoin que d’une revue de contenu ponctuelle, d’une critique de design ou d’une checklist de QA manuelle sans surveillance continue. Le principal frein à l’adoption est souvent le contexte : canary fonctionne au mieux quand vous pouvez le pointer vers la bonne cible en production et définir clairement ce que signifie un comportement « normal ».

Comment utiliser le skill canary

Installation et configuration de canary

Installez canary avec le flux de skills gstack montré dans le dépôt, puis commencez par lire SKILL.md et SKILL.md.tmpl. Le skill n’embarque pas de dossiers d’assistance supplémentaires ; le contexte d’installation principal se trouve donc dans ces deux fichiers. Si vous adaptez le guide canary à votre propre dépôt, gardez explicitement dans votre invite l’URL de production, l’événement de déploiement et la source de la base de référence.

Ce qu’il faut fournir dans votre première invite

Donnez à canary le minimum d’informations nécessaire pour que la surveillance ait du sens :

• l’application ou la route à surveiller
• ce qui a changé dans le déploiement
• à quoi ressemblait le « bon » état avant la release
• ce qui doit être considéré comme un échec
• combien de temps observer

Une invite faible dit « surveille l’application ». Une invite plus solide dit « surveille /checkout après le déploiement d’aujourd’hui, compare les captures d’écran à la base de référence d’avant release et signale toute nouvelle erreur de console, tout bouton cassé ou tout décalage de mise en page sur 10 minutes ».

Workflow conseillé pour l’usage de canary

Commencez par le moment du déploiement, puis passez de la base de référence à l’observation et enfin au verdict. Vérifiez d’abord la branche ou l’environnement cible, définissez ensuite le comportement de référence, puis demandez des contrôles en conditions réelles et un rapport d’anomalies. Si vous utilisez le skill de façon interactive, la décision la plus importante au départ est de savoir si vous voulez une surveillance proactive ou une simple passe de vérification, car cela change la manière dont le skill doit cadrer ses contrôles.

Fichiers à lire en premier

Lisez d’abord SKILL.md, puis SKILL.md.tmpl pour comprendre comment le skill est généré et quelles parties relèvent de la logique de workflow. Portez une attention particulière aux sections sur le préambule, la sécurité en mode plan, l’appel du skill pendant le mode plan et le routage. Ce sont les éléments les plus susceptibles d’influer sur le déclenchement correct de canary et sur le bon moment d’exécution.

FAQ sur le skill canary

canary est-il réservé au monitoring de production ?

Non. Il est conçu pour des vérifications canary après déploiement, donc la production est le cas d’usage le plus évident, mais le même schéma fonctionne aussi sur un environnement de staging ou tout autre environnement vivant où vous voulez comparer l’état avant/après une modification.

En quoi canary diffère-t-il d’une invite de QA classique ?

Les invites classiques demandent souvent une inspection unique. canary est plus opérationnel : il est pensé pour repérer des régressions, capturer des preuves et comparer l’état actuel à l’état précédent. Il est donc plus adapté quand vous avez besoin de canary pour le monitoring plutôt que d’une revue générale.

canary est-il adapté aux débutants ?

Oui, si vous pouvez décrire le déploiement, la page et les conditions d’échec. La difficulté n’est pas d’utiliser le skill, mais de lui donner assez de contexte pour évaluer le changement par rapport à une base de référence pertinente. Si vous ne pouvez pas définir ce qui a changé ou ce qui doit rester stable, la sortie sera moins solide.

Quand ne faut-il pas utiliser canary ?

Ne l’utilisez pas pour une analyse produit large, de l’édition de contenu ou des tâches qui ne dépendent pas de la santé d’une application en direct. Ce n’est pas non plus un bon choix si vous n’avez pas de base de référence, pas d’accès à l’environnement cible ou pas de seuil clair de réussite/échec pour le déploiement.

Comment améliorer le skill canary

Donner à canary une base de référence plus précise

L’amélioration la plus utile consiste à mieux définir ce qui est normal. Ajoutez des captures d’écran d’avant déploiement, des URL connues pour être fiables, le comportement attendu de la console et tous les éléments d’interface critiques qui doivent rester intacts. Plus la base de référence est précise, moins le skill risque de signaler à tort des différences sans gravité.

Énoncer les modes de défaillance qui vous importent

canary devient nettement plus utile quand vous nommez à l’avance les régressions probables : écran blanc, données API manquantes, navigation cassée, décalages CSS, erreurs de console, chargement de page lent ou échecs d’interaction. Un skill canary qui sait quoi chercher produira une sortie plus exploitable pour la décision qu’une consigne générique du type « trouve des problèmes ».

Itérer après la première exécution

Utilisez le premier passage pour voir ce que le skill remonte, puis resserrez l’invite. S’il produit du bruit, réduisez le périmètre des routes ou augmentez le seuil d’anomalie. S’il passe à côté de problèmes importants, ajoutez les parcours utilisateur clés, le texte attendu ou les points de comparaison. Un bon usage du guide canary est itératif : base de référence, vérification, ajustement, relance.