“D'autres modèles continuaient à pointer du doigt la même chose encore et encore, même après que nous l'avions corrigée. Quand nous avons essayé Enter Pro, il a compris quelle était la cause réelle.”

WhyVenv a conçu Kronos, un agent autonome de réponse aux incidents pour le Quackathon, afin d'aider les ingénieurs à passer plus rapidement des erreurs de production à la cause racine.

Le bipeur n'est que le début

Lorsque la production tombe en panne, l'alerte est rarement la partie la plus difficile.

Grafana peut vous dire que quelque chose est en panne. Les logs peuvent vous dire que quelque chose a échoué. Un tableau de bord peut clignoter en rouge de manière assez bruyante pour réveiller quelqu'un à 2 heures du matin.

Mais après cela, le vrai travail commence.

Un ingénieur doit encore ouvrir les logs, comprendre l'erreur, chercher dans la base de code, deviner quelle fonction est concernée, décider si le problème est urgent et déterminer si la prochaine étape appropriée est un ticket GitHub, un correctif ou une escalade complète.

Ce fossé entre savoir que quelque chose a cassé et comprendre ce qui a cassé est l'endroit où la réponse aux incidents devient douloureuse.

C'est également là que Dawood Khan a trouvé l'idée de Kronos.

Dawood a étudié l'IA, mais après l'université, il s'est rapproché de l'ingénierie système. Son intérêt n'était pas abstrait. Il avait vu comment les systèmes de production échouent, comment les équipes réagissent et quelle quantité d'investigation manuelle subsiste encore entre une alerte et une résolution.

Lors d'un événement Grafana à Hyderabad, le problème est devenu encore plus clair. Les ingénieurs décrivaient le même schéma : le système tombe en panne, quelqu'un reçoit l'appel, puis l'équipe commence le travail familier de traçage manuel de la panne.

Le Quackathon est devenu le moment de construire quelque chose de différent. Conçu par WhyVenv, Kronos a remporté la deuxième place au Quackathon, se démarquant dans le défi Track 01: Software - The Sentient Workspace pour avoir transformé la réponse aux incidents de production en un flux de travail agentique.

Ce que WhyVenv a construit

Le projet de WhyVenv était Kronos, un agent autonome de réponse aux incidents conçu pour le défi Sentient Workspace du Quackathon.

L'idée était simple, mais ambitieuse :

Kronos reçoit les erreurs de production, lit les logs, récupère le code pertinent, demande à un modèle d'IA de diagnostiquer la cause racine probable, puis décide de la suite à donner.

Parfois, cela signifie ouvrir un ticket GitHub.

Parfois, selon la gravité du problème, cela signifie tenter un correctif.

Le but n'est pas seulement de notifier l'ingénieur que la production est en panne. Le but est de donner à l'ingénieur une longueur d'avance sur le travail qui suit normalement l'alerte.

Selon les mots de Dawood lors de l'interview, les alertes Grafana permettaient de savoir facilement quand quelque chose était en panne. Le problème résidait dans tout ce qui suivait : trouver ce qui avait causé le problème, où se situait le bug et quelle action l'équipe devait entreprendre.

Kronos a été conçu pour automatiser cette couche intermédiaire.

La vision technique derrière Kronos

“La partie dont j'étais le plus fier était l'étape de récupération. Au lieu d'utiliser uniquement des AST ou des plongements (embeddings), nous avons travaillé à partir des logs de trace, car c'est ainsi que les ingénieurs trouvent habituellement le problème.”

La partie dont Dawood était le plus fier n'était pas le tableau de bord, l'intégration GitHub, ni même le diagnostic par l'IA.

C'était l'étape de récupération.

De nombreux systèmes de codage par IA tentent de comprendre une base de code via des plongements, de l'analyse AST ou un chargement de contexte large. Kronos a emprunté une voie plus naturelle pour un ingénieur : partir des logs de trace et les utiliser pour restreindre la recherche.

Ce choix est important.

Lorsque les ingénieurs déboguent des pannes de production, ils commencent rarement par demander à un modèle d'IA de lire l'intégralité du dépôt. Ils regardent l'erreur. Ils suivent la trace d'exécution (stack trace). Ils effectuent un grep dans le code. Ils passent du symptôme à la source.

Kronos a été conçu autour de ce même instinct.

Le système utilise les logs comme point d'entrée, récupère le code qui semble le plus pertinent, et seulement ensuite intègre le modèle d'IA dans le flux de travail. Cela fait du modèle moins un oracle omniscient qu'un réviseur travaillant à partir d'un ensemble ciblé de preuves.

Dawood a été clair sur le fait que cette approche a encore besoin d'être perfectionnée avant de pouvoir être utilisée en toute confiance à grande échelle. Mais pour la démo, cela a fonctionné. Plus important encore, cela reflétait un véritable instinct de produit : les meilleurs systèmes d'IA ne remplacent pas aveuglément le flux de travail d'ingénierie. Ils apprennent de la manière dont les ingénieurs résolvent déjà les problèmes.

Construire la pile d'observabilité avec Enter Pro

Kronos devait fonctionner avec des outils que l'équipe n'avait pas utilisés en profondeur auparavant.

Grafana. Prometheus. Loki. Tableaux de bord. Logs. Métriques. Alertes.

Pour une équipe de hackathon, cela représente beaucoup d'infrastructures à comprendre avant même que le produit réel puisse commencer à fonctionner.

C'est là que Enter Pro s'est révélé utile pour WhyVenv.

L'équipe a utilisé Enter Pro tout au long du projet pour la recherche, l'affinage des idées et le débogage. Dawood et ses coéquipiers l'ont utilisé pour comprendre la pile d'observabilité, comprendre comment les composants s'assemblaient et surmonter les problèmes d'intégration lorsque le système ne se comportait pas comme prévu.

Un moment en particulier s'est démarqué.

L'équipe ne comprenait pas pourquoi ses alertes de données n'arrivaient pas correctement. Ils avaient essayé d'autres modèles d'IA, mais Dawood avait l'impression que certains d'entre eux tournaient en rond autour du même point alors même que l'équipe l'avait déjà corrigé.

Lorsqu'ils ont essayé Enter Pro, cela les a aidés à identifier la cause réelle plus directement.

C'est le genre de moment qui compte dans un sprint de développement. Pas une réponse de démonstration polie. Pas une suggestion générique. Un coup de pouce concret pour surmonter un véritable obstacle.

Pour WhyVenv, Enter Pro n'était pas seulement un endroit pour générer du code. C'était un moyen de raisonner rapidement à travers des systèmes inconnus afin de continuer à construire.

Deux jours de concentration

Dawood avait planifié le projet avant que l'équipe ne commence le développement sérieux.

Il savait ce qu'ils voulaient construire. Il avait réfléchi à l'architecture de base. Il avait une idée approximative de la manière dont le travail devait être réparti.

Puis le rythme réel du hackathon a pris le dessus.

Le premier jour n'a pas été uniquement consacré au code. L'équipe a passé du temps ensemble, a discuté, a plaisanté et a trouvé ses marques. Le véritable développement est venu après cela : un sprint concentré où ils ont divisé le travail, recherché des éléments inconnus, implémenté le flux principal et affiné le produit jusqu'à ce qu'il tienne la route.

L'architecture a commencé simplement :

rapport de plantage -> code pertinent -> diagnostic LLM -> ticket ou correctif.

Ensuite, chaque partie est devenue plus précise à mesure que l'équipe construisait.

Cette simplicité est en partie ce qui rend Kronos si séduisant. Il ne commence pas par une théorie compliquée de logiciel agentique. Il commence par un flux de travail que tout ingénieur d'astreinte comprend : quelque chose a cassé, trouvez la cause, décidez de la suite à donner.

Ce que Kronos suggère sur les agents d'IA

Kronos n'est pas un chatbot assis à côté d'une base de code.

Il est plus proche d'un agent de flux de travail : un système qui reçoit un signal du monde réel, rassemble les bonnes preuves, ne demande un raisonnement que là où il est utile, puis achemine le résultat vers les outils que les ingénieurs utilisent déjà.

Cette distinction est importante.

Dawood est sensible aux problèmes de coût et de contrôle liés aux systèmes d'IA. Dans l'interview, il a parlé de l'utilisation des jetons (tokens), des appels de modèles coûteux et de l'importance de ne pas laisser un agent tout gérer lorsque la logique backend déterministe peut effectuer une partie du travail plus efficacement.

C'est un instinct mature pour quelqu'un qui construit avec l'IA en 2026.

L'avenir des agents d'IA ne consistera pas seulement à utiliser des modèles plus puissants. Il s'agira également de savoir quand ne pas les utiliser. Quelles parties doivent être du code ? Quelles parties doivent être de la récupération ? Quelles parties doivent relever du raisonnement du modèle ? Quelles parties doivent rester sous contrôle humain ?

Kronos, même en tant que projet de hackathon, oriente vers cette question.

Quelle est la prochaine étape

Le projet doit encore répondre à des questions avant d'être prêt pour la production :

Dans quelle mesure l'approche de récupération s'adapte-t-elle à des bases de code plus importantes ?
Comment calibrer la gravité et l'autonomie ?
Quand un agent doit-il ouvrir un ticket plutôt que de tenter un correctif ?
Quelle quantité de contexte est suffisante pour qu'un modèle diagnostique un incident réel ?
Que doivent approuver les humains avant que quoi que ce soit n'atteigne la production ?

Ce ne sont pas de petites questions. Ce sont précisément les questions qui font que Kronos mérite qu'on s'y intéresse.

Parce que les incidents de production ne vont pas disparaître. La seule question est de savoir si chaque réponse doit commencer par une panique manuelle.

Kronos imagine une première étape différente : une étape où le système qui constate la panne peut également commencer à la comprendre.

C'est ce que Enter existe pour soutenir.

Pas seulement du code plus rapide. Un passage plus rapide d'un véritable point de douleur à un produit fonctionnel.

Et pour WhyVenv, ce mouvement a suffi à transformer un schéma d'ingénierie douloureux en l'un des projets gagnants du Quackathon.

Explorer Kronos.

Cette histoire fait partie de notre série Quackathon Builder, où nous analysons un projet à la fois pour comprendre ce que les créateurs ont réalisé avec Enter Pro, pourquoi ils l'ont construit et ce que leur travail nous apprend sur l'avenir de la création de logiciels propulsés par l'IA. Restez à l'écoute.