Vous lancez trois agents de codage sur trois tâches, puis vous passez les vingt minutes suivantes à faire le tour des onglets de terminal pour répondre à une seule question : lequel a besoin de moi là, tout de suite ? L'un tourne encore. Un autre attend un y/n que vous n'avez jamais vu. Un troisième s'est terminé en vert il y a une heure et a discrètement construit la mauvaise chose. Rien ne vous en a informé. Vous avez dû aller chercher l'information vous-même.
C'est précisément ce vide que l'observabilité des agents de codage est censée combler. L'observabilité, empruntée à l'ingénierie système, est la capacité à comprendre ce que fait un processus en cours à partir des signaux qu'il émet, sans s'y attacher directement (OpenTelemetry propose une bonne introduction). Pour les agents de codage, la norme serait la suivante : vous devriez pouvoir répondre à « que fait chaque agent, qu'est-ce qui a échoué et qu'est-ce qui nécessite un humain ? » depuis une vue partagée, et non en suivant une session. La plupart des configurations en sont incapables. Elles ont un statut quelque part et un journal ailleurs, et appellent ça de l'observabilité. Ce n'est pas le cas.
Cet article passe en revue les trois signaux qu'un agent de codage émet réellement, les signaux de défaillance qui méritent de déclencher une alerte, et l'endroit où une couche de tâches partagée comme Sharkly transforme une sortie brute en information exploitable. Sharkly se place au-dessus des agents que vous exécutez déjà ; vous avez déjà des agents de codage, et l'objectif ici est de rendre leur travail lisible quand il y en a plus d'un.
Statut, journaux et signaux de défaillance : trois choses bien distinctes
Ces trois mots sont employés de façon interchangeable, et cette confusion est à l'origine de la plupart des mauvaises configurations de supervision. Ils répondent à des questions différentes.
Le statut est l'état résumé d'une exécution. En cours, en attente d'une entrée, terminé ou échoué. C'est un seul champ, peu coûteux à lire, et il vous dit où en est une exécution, pas ce qu'elle a fait. Un statut n'est pas de l'observabilité ; c'est le plus petit fait concernant une exécution.
Les journaux sont la trace d'exécution brute. Chaque appel d'outil, chaque modification de fichier et chaque réponse du modèle, dans l'ordre. Les journaux vous disent ce qui s'est passé une fois que vous savez déjà que quelque chose a mal tourné. Ils sont indispensables pour un post-mortem et inutiles comme signal en temps réel, car personne ne surveille cinq journaux qui défilent en même temps. Un journal n'est pas un signal tant que quelque chose n'en extrait pas de sens.
Les signaux de défaillance sont des alertes dérivées. Ce sont les conditions précises qui justifient de vous interrompre : un agent bloqué, une exécution terminée en vert dans la mauvaise direction, un budget épuisé en pleine tâche. Le signal de défaillance est ce que vous voulez réellement, et c'est la couche que presque toutes les configurations maison sautent, car le dériver suppose de transformer les journaux en événements plutôt que de simplement les stocker.
Le piège, c'est de s'arrêter aux deux premières. Statut plus journaux donne l'impression d'observabilité parce qu'on dispose d'un état et d'un enregistrement. Mais la seule question qui passe à l'échelle, « lequel de mes agents a besoin de moi ? », vit entièrement dans la troisième couche.
Les signaux de défaillance qui comptent vraiment
L'observabilité des services web surveille les plantages et la latence. Les agents de codage échouent différemment, et les défaillances qui vous coûtent un après-midi sont rarement celles qui apparaissent sous forme de statut rouge. Voici les signaux qui méritent d'être dérivés.
| Signal | Ce que cela signifie | Pourquoi le statut et les journaux le manquent |
|---|---|---|
| Blocage silencieux | L'agent attend une saisie ou un secret manquant et ne produit aucune sortie | Le statut affiche toujours « en cours » ; rien ne lève la main |
| Vert mais faux | L'exécution s'est terminée avec succès mais a fait la mauvaise chose | Le statut indique « terminé » ; seul l'examen du diff le révèle |
| Vérification ignorée | A déclaré avoir terminé sans lancer le typecheck, les tests ou le build | Les journaux contiennent l'omission, mais personne ne lit un journal qui passe |
| Épuisement du budget | Quota du modèle ou plafond de dépenses atteint en cours de tâche | La défaillance se manifeste par une réponse tronquée, pas par une alerte |
| Conflit latent | Deux agents ont modifié les mêmes fichiers dans des worktrees séparés | Les deux exécutions sont « terminées » ; la collision attend au merge |
| Thrashing | L'agent modifie, annule et remodifie le même fichier en boucle | Chaque étape prise isolément semble correcte dans le journal |
Le schéma commun aux six : la défaillance est invisible au niveau du statut et enfouie au niveau du journal. « Vert mais faux » est celui que l'on sous-estime le plus. Un agent de codage qui termine avec assurance la mauvaise tâche est identique à celui qui a visé juste, jusqu'à ce que la revue avec des preuves au niveau de la tâche le détecte. Une observabilité qui ne rapporte que les codes de sortie signalera cette défaillance comme un succès.
Deux d'entre eux sont structurels plutôt que comportementaux. Les conflits latents sont la raison pour laquelle le travail parallèle sur un même dépôt exige des worktrees isolés par tâche, afin que les chevauchements de fichiers apparaissent avant le merge plutôt que pendant. L'épuisement du budget est la raison pour laquelle le suivi des dépenses entre agents a sa place dans la même vue que le statut ; une exécution qui s'est arrêtée discrètement faute de quota est un signal de défaillance, pas une tâche terminée.
Quel niveau d'observabilité selon la taille de l'équipe
Vous n'avez pas besoin des six signaux dès le premier jour. La bonne quantité d'instrumentation évolue avec le nombre d'agents exécutés et le nombre de personnes qui doivent les voir.
| Configuration | Ce qu'il faut instrumenter | Où ça casse |
|---|---|---|
| Un agent, une tâche | Statut uniquement ; lire le journal en cas d'échec | Rien, jusqu'à ce que vous lanciez un second agent |
| Plusieurs agents en solo | Statut par exécution, plus les signaux de blocage et de « vert mais faux » | Vous déduisez l'état à partir du silence et manquez les blocages |
| Petite équipe, dépôts partagés | Les six signaux, plus l'état de revue, dans une vue partagée | Votre supervision vit sur un seul ordinateur portable que personne d'autre ne peut voir |
| Équipe plus grande, nombreux dépôts | Ce qui précède, plus la propriété par exécution, le budget et la piste d'audit | Personne ne peut répondre à « qui a lancé quoi » une semaine plus tard |
Pour être honnête : un développeur solo qui exécute un seul agent sur des travaux sans lien dispose de toute l'observabilité nécessaire dans un simple terminal. L'équation change dès que les agents sont plus nombreux que vos écrans, que le travail s'exécute sur des machines où vous n'êtes pas assis, ou qu'une autre personne doit voir le même tableau. Au-delà de cette limite, un champ de statut et un répertoire de journaux ne suffisent plus.
Quand les journaux bruts et un seul runtime suffisent
Accordez aux outils intégrés leur meilleure version, car pour beaucoup de travaux, ils gagnent. Claude Code et Codex conservent tous deux une trace de session lisible, et pour un seul agent sur une seule tâche, cette trace constitue votre observabilité. Vous l'avez lancé, vous le surveillez, vous lirez le journal s'il s'arrête. Ajouter une couche de gestion à ce stade n'est que de la surcharge pure.
Utilisez la sortie propre au runtime lorsque vous exécutez un ou deux agents, sur des travaux sans lien, qui ne sont jamais transmis à quelqu'un d'autre. Recourez à une couche d'observabilité partagée quand les exécutions dépassent votre capacité d'attention, quand elles s'exécutent quelque part où vous ne pouvez pas suivre le flux, ou quand la revue doit devenir une activité d'équipe plutôt que privée. Ce dernier cas est le tueur silencieux : cinq agents qui terminent en parallèle ne sont pas une victoire si la revue de leurs diffs se remet en file d'attente pour un seul humain. Les agents sont devenus plus rapides ; vous, plus lent. C'est aussi un problème d'observabilité, et aucun runtime isolé ne le résout, car le signal qui compte, « cette exécution est terminée et attend votre revue », vit entre les agents, pas à l'intérieur de l'un d'eux.
L'observabilité quand les résultats remontent à la Tâche
Une couche de tâches fait passer l'unité d'observabilité de « un processus dans un volet » à « une Tâche avec un état ». C'est le changement autour duquel Sharkly est conçu, et il correspond aux trois signaux à la fois.
Chaque exécution d'agent est rattachée à une Tâche. Le statut, la progression, les blocages et les résultats reviennent dans la chronologie de cette Tâche au lieu de rester dans un journal que vous seul pouvez voir. Les signaux de défaillance apparaissent au même endroit : les exécutions qui nécessitent un humain arrivent dans la Inbox, si bien que la question cesse d'être « est-ce que quelque chose a terminé ? » pour devenir « voici ce qui attend ma décision ». Les agents recherchent, exécutent, testent et rendent compte ; les humains fixent la direction, accordent l'autorité et acceptent le résultat. L'automatisation s'arrête là où le jugement de l'équipe est requis.
La frontière est importante, car il est facile de se tromper. Sharkly n'exécute pas l'agent et n'écrit pas le code. Claude Code, Codex et les autres runtimes que vous utilisez déjà assurent toujours l'exécution. Sharkly ajoute autour d'eux la couche de tâche partagée, de Computer, de contexte et de revue, afin que le contexte, la progression, les blocages, les résultats et la revue humaine restent visibles de la demande jusqu'à la livraison. Pour une vue plus complète de ce que ce tableau partagé doit afficher, voir ce dont un tableau de bord d'agents de codage IA a réellement besoin, et pour l'angle de la supervision en direct, comment surveiller des agents de codage exécutés en parallèle.
Si vous souhaitez continuer à utiliser plusieurs agents de codage plutôt que de vous engager dans un seul écosystème, cette vue partagée et centrée sur les signaux est le problème autour duquel Sharkly est conçu. Vous pouvez exécuter vos agents de codage existants via Sharkly et conserver tous les runtimes que vous utilisez déjà.
FAQ
L'observabilité des agents de codage, est-ce la même chose que la journalisation ? Non. La journalisation stocke ce qui s'est passé. L'observabilité, c'est pouvoir répondre à ce que fait chaque agent, ce qui a échoué et ce qui vous sollicite, sans lire ces journaux un par un. Les journaux sont une entrée de l'observabilité, pas la totalité de celle-ci.
Quel est le signal de défaillance le plus important à instrumenter en premier ? Le blocage silencieux. Un agent qui affiche « en cours » alors qu'il attend indéfiniment une saisie que vous n'avez jamais vue est la façon la plus courante dont le travail parallèle meurt discrètement. Faites en sorte que les exécutions bloquées lèvent la main avant de vous lancer dans quoi que ce soit de plus sophistiqué.
Puis-je obtenir cela à partir de la sortie intégrée de mon agent de codage ? Pour un seul agent, oui. La trace de session propre au runtime suffit. La sortie intégrée n'offre aucune vue inter-agents : elle ne peut donc pas vous dire laquelle de cinq exécutions vous sollicite, ce qui est précisément la question qui apparaît dès que vous dépassez un seul agent.
