Le besoin
Des éditeurs de petites applications : une app d'engagement des salariés vendue aux entreprises et déclinée en marque blanche, un SaaS de gestion pour PME. Leurs demandes arrivent par email, les erreurs de production s'accumulent dans les logs, et certains bugs ne sont jamais signalés parce qu'ils ne se voient pas à l'écran.
S'y ajoutent des exigences de conformité RGPD qui doivent décrire l'application réelle, pas l'application idéale.
Ce qu'on a fait
- Une routine Claude automatisée par application. Chaque jour, elle lit les emails du client, les logs et les erreurs de production, l'état des pull requests, et produit un rapport de veille. Les correctifs passent par des pull requests et une intégration continue (lint, typage, tests). Une alerte part dès qu'une action manuelle ou un nouveau build est nécessaire.
- Des diagnostics sur données réelles. 14 500 déclarations analysées pour comprendre un comportement suspect pendant un challenge : de la saisie manuelle répétée, ni un bug ni un robot. Quatre mécanismes de correction simulés sur les vraies données avant de mettre le bon en production.
- Une conformité vérifiée, pas déclarée. Quatre documents RGPD rédigés puis vérifiés phrase par phrase contre l'application et sa base, suivis des correctifs associés : cloisonnement des données entre utilisateurs, consentement non pré-coché, masquage des statistiques sur les petits effectifs.
Schéma de la missionMaintenance applicative
Des agents qui lisent les logs chaque matin et trouvent les bugs que personne ne signale.
- 01Une routine Claude automatisée par application
- 02Des diagnostics sur données réelles
- 03Une conformité vérifiée, pas déclarée
Résultat
1 / jour
rapport de veille par application : erreurs, logs, demandes clients
Le résultat
- Un import automatique en échec total depuis plusieurs mois, repéré dès les premiers contrôles quotidiens : 26 documents bloqués identifiés.
- Un bug qui bloquait l'ensemble des emails d'une application, alors que l'interface affichait un succès : détecté, expliqué au client et corrigé dans la foulée.
- Des erreurs de production repérées dans les rapports quotidiens et corrigées par pull request.
- Un mécanisme anti-abus mis en production, puis validé dès le lendemain.
Ce qu'on en retient
Le bug le plus coûteux est celui que personne ne signale. Avec une routine qui lit les logs chaque matin, la maintenance devient proactive : on corrige avant d'être appelé.
« C'est la première fois qu'on me remet un document juridique qui décrit la plateforme telle qu'elle est et pas telle qu'on voudrait qu'elle soit. »
