Suite du POC puit de logs Azure. La semaine dernière, on avait la chaîne logs → tickets en un clic. Cette semaine, on a ajouté la mémoire.

Le constat : les mêmes erreurs reviennent, et à chaque fois quelqu’un passe du temps à diagnostiquer avant de retrouver la résolution. Pas de capitalisation, pas de contexte.

Ce qu’on a ajouté :

• Une base de connaissances d’erreurs connues : pattern, titre, résolution suggérée, priorité. Quand on clique sur “Ticket” à côté d’un log, le dashboard cherche automatiquement si l’erreur est connue et pré-remplit la modale.

• Priorité et assignation : le ticket part avec la bonne priorité (suggérée par la KB ou choisie manuellement) et la bonne personne.

• La résolution de la KB est injectée dans le body du ticket Azure DevOps. L’opérateur qui ouvre le Work Item a la marche à suivre sous les yeux.

• Un compteur “logs matchants” sur chaque erreur connue : rouge si 5+, orange si 1-4, gris sinon. On voit d’un coup d’œil quelles erreurs sont actives.

Ce qui a cassé :

• J’ai d’abord utilisé SQLite (better-sqlite3) pour stocker la KB. Ça marchait en local. En production sur App Service Linux, crash-loop : le module natif C++ n’est pas compatible avec le conteneur Azure. La crash-loop a consommé le quota CPU du plan gratuit en quelques minutes. App bloquée, impossible de redéployer. Remplacement par un fichier JSON — zéro dépendance native, ça marche partout.

• L’UX s’est trouvée en testant, pas en planifiant. La KB placée en onglet à côté des sources de logs ? Pas logique. Déplacée dans un drawer latéral accessible depuis la navbar. Mieux.

La leçon la plus coûteuse : un npm install qui passe en local mais casse en production, ça peut bloquer un déploiement complet. Sur du PaaS, toujours privilégier les alternatives pure JS.

Le retour complet est sur mon blog — avec les screenshots, les diagrammes et le tableau de ce qui a cassé.

#Azure #DevOps #Monitoring #NodeJS #RetourExperience