Aller au contenu principal
TL
Illustration : des erreurs éparses convergent vers un moteur central puis ressortent classées en fiches.

Base de connaissance des erreurs

Donner à une équipe un outil qu'elle utilise vraiment, pour voir ses erreurs et les corriger vite.

Rôle

Conception et développement

Période

Stack technique
  • NestJS
  • TypeScript
  • React
  • TypeORM
  • PostgreSQL
  • Azure Functions
  • Azure OpenAI
  • Entra ID
projets câblés
7
erreurs documentées
~200
jusqu'à la v1 en prod
5 jours
temps de résolution
< 1 sem.
01

Le contexte

  • Quand un développeur rencontre une erreur qu'un collègue a déjà résolue, rien n'en garde la cause ni le correctif : il contacte quelqu'un ou redécouvre le problème de zéro.
  • Cette connaissance reste dans la tête des personnes et se disperse d'un projet à l'autre ; un départ ou un changement d'équipe l'emporte avec lui.
  • L'équipe suit mal ses erreurs : rien ne les remonte de façon centralisée, et sur plusieurs projets elle ignore lesquelles tournent en production, où elles peuvent dériver des mois.
  • Une autre personne a développé une première version pour un autre besoin, qui a dérivé vers l'idée d'une base de connaissance ; l'app ne fait ni l'un ni l'autre, et ne rencontre pas le taux d'adoption souhaité.
02

Ma mission

  • Redéfinition du périmètre à partir du besoin réel de l'équipe, après une première version restée sans usage.
  • Conception et développement de l'application de bout en bout.
  • Définition du contrat d'ingestion et de la façon dont chaque application envoie ses erreurs, quelle que soit sa stack.
  • Conception du regroupement des erreurs en fiches et des règles de tri automatique.
  • Mise en place de la chaîne de livraison sur Azure DevOps, avec analyse Sonar, SAST Fortify et contrôle des dépendances.
  • Information hebdomadaire des équipes et collecte des retours pour lever les frictions d'usage.
03

Décisions et arbitrages

  1. 01

    Recadrer et reconstruire plutôt que reprendre l'existant

    Problème

    Une première version existe mais ne répond ni au besoin d'origine ni à celui de l'équipe, et ne rencontre pas le taux d'adoption souhaité.

    Solution

    Redéfinition du périmètre sur le besoin réel, puis reconstruction et mise en prod d'une v1 en une semaine.

    Pourquoi ce choix

    Le cadrage est le vrai problème, plus que le code ; reprendre l'existant aurait reconduit le mauvais périmètre. Depuis, sur des projets aveugles depuis des mois, l'équipe corrige les erreurs en quelques jours et leur flux tombe de plusieurs par jour à une par semaine à usage égal.

  2. 02

    Construire une base de connaissance plutôt qu'un traceur du marché

    Problème

    L'équipe n'a aucun suivi d'erreurs, et des produits comme Sentry couvriraient la remontée et l'alerting.

    Solution

    Ingestion maison et regroupement des erreurs en fiches, où l'équipe renseigne à la main la cause et le correctif. Le tout sur l'hébergement Azure et l'authentification Entra ID en place.

    Pourquoi ce choix

    Sentry remonte des événements, là où l'équipe veut une connaissance qu'elle entretient : cause, correctif, réponse de référence par projet. En contrepartie, le regroupement et les règles restent à concevoir et à maintenir.

  3. 03

    Reconnaître une même erreur sous ses différentes formes

    Problème

    Une même cause peut se présenter sous plusieurs codes HTTP, et un regroupement trop fin crée une fiche par variante pour un seul problème.

    Solution

    L'empreinte regroupe par projet, contexte (route ou opération) et type d'exception, en écartant volontairement le code de statut. Des règles par projet normalisent le contexte pour absorber le bruit de scan.

    Pourquoi ce choix

    Le code de statut varie sans changer le problème sous-jacent ; l'inclure éclaterait une même cause en plusieurs fiches. Le juste niveau de regroupement se règle ensuite projet par projet.

  4. 04

    Découpler la réception des logs de leur écriture en base

    Problème

    Les applications émettent des logs à un débit soutenu, et une écriture en base par log coûterait cher à ce rythme.

    Solution

    L'API accuse réception aussitôt et empile les logs en mémoire, puis les écrit en base par paquets à intervalle court.

    Pourquoi ce choix

    Le regroupement tient le débit là où une écriture par log ferait de la base le goulot. En échange, un crash perd le dernier paquet encore en mémoire, ce qui reste acceptable pour de la télémétrie.

04

Ce que ce projet m'a apporté

  • Reprise d'un produit interne et recadrage sur le besoin réel avant d'écrire une ligne.
  • Conduite de l'adoption d'un outil transverse par une information hebdomadaire et des boucles de retour régulières.
  • Co-construction du contrat d'ingestion avec l'équipe, en s'appuyant sur les personnes qui maîtrisent les stacks hors de son expertise.
  • Conception d'un agent d'intégration qui pose lui-même le client dans un dépôt et ouvre la PR, en s'adaptant à la stack.
  • Usage d'outils IA pour accélérer la conception et déplacer son attention vers la relecture du code et la sécurité.

Galerie

Voir d'autres projets