Devbrau reçoit les erreurs de vos SDK Sentry, en explique la cause et, à votre demande, ouvre la pull request qui corrige, avec un test qui le prouve. Données stockées en Europe. Une seule ligne à changer : le DSN.
Plan Free : 5 000 événements et 10 analyses IA par mois.
TypeError: Cannot read properties of undefined (reading 'items')
checkout/cart.ts in totalFor
Un incident, étape par étape, avec un seul geste de votre part avant la pull request. Chaque étape laisse une trace que vous pouvez relire.
Vos SDK Sentry envoient, Devbrau reçoit. Les données personnelles sont retirées avant toute écriture.
| SDK | @sentry/node, inchangé |
|---|---|
| user.email | [filtré] |
| user.ip_address | [filtré] |
| Écrit en base | après nettoyage, en Europe |
1 234 événements, une seule issue. Résolue en 4.1.0, revenue en 4.2.1 : c'est une régression, l'équipe est prévenue.
Pour chaque nouvelle issue et chaque régression, l'IA explique la cause probable, désigne les fichiers en cause et indique sa confiance. Ce qu'elle a le droit de lire, c'est vous qui le décidez, projet par projet.
Non exécuté : au niveau 0, aucune analyse IA n'est faite et rien n'est envoyé au modèle.
totalFor lit session.cart.items sans vérifier que le
panier existe : quand la session invitée expire pendant le paiement,
session.cart est indéfini (src/checkout/cart.ts,
ligne 52).
Hypothèse, d'après la stack trace et les breadcrumbs :
session.cart est indéfini quand la session invitée expire pendant le
paiement. Aucun fichier du dépôt n'a été lu.
| Données utilisées | stack trace, breadcrumbs, contexte de l'événement · 2 fichiers lus au commit de la release |
|---|---|
| Fichiers en cause | src/checkout/cart.ts · src/session/guest.ts |
| Confiance | élevéemoyenne |
src/checkout/cart.ts L40–88 @ a41f9c2src/session/guest.ts L1–30 @ a41f9c2À ce niveau, l'IA ne lit aucun fichier : son diagnostic s'appuie sur les données de l'événement, et sa confiance le reflète.
Le diagnostic vous convainc : un clic sur « Proposer un correctif » lance l'agent. Sans cette demande, rien ne touche à votre dépôt.
Non proposé : les correctifs demandent le niveau 3.
Dans un conteneur isolé, l'agent écrit un test qui reproduit l'erreur et corrige le code. Devbrau rejoue ensuite lui-même le test et la suite existante : le test doit échouer avant, passer après, et la suite rester verte. Sinon, pas de PR : le compte rendu s'affiche dans l'issue.
Non exécuté : le correctif demande le niveau 3.
| Exécution | Commande | Résultat | Écart |
|---|---|---|---|
| Avant | pnpm vitest run checkout/cart.test.ts | 1 échec | Échec |
| Après | pnpm vitest run checkout/cart.test.ts | 0 échec | Conforme |
export function totalFor(session: Session) { - return session.cart.items.reduce(sum, 0); + const cart = session.cart ?? emptyCart(); + return cart.items.reduce(sum, 0); }
Sur GitHub ou Azure DevOps, toujours sur une branche devbrau/*, jamais sur la branche par défaut. Le clone, la branche et la PR sont inscrits au journal des accès au code.
Non exécuté : aucune branche n'est créée sous le niveau 3.
devbrau/fix-812-1 vers main
Vous relisez. Vous fusionnez, ou pas. Une fois la release déployée, vous passez l'issue en « résolue » ; si l'erreur revient, Devbrau la signale comme régression.
Pas de PR à ce niveau : votre équipe corrige. Une fois la release déployée, vous passez l'issue en « résolue » ; si l'erreur revient, Devbrau la signale comme régression.
Logs, temps de réponse, sites, tâches planifiées, serveurs : une seule application, un seul DSN, les mêmes alertes.
Les logs de vos SDK et de vos conteneurs, nettoyés des données personnelles, reliés à l'erreur par leur trace.
Le temps de réponse de chaque route, p50 à p99, et la cascade des requêtes SQL et HTTP de la plus lente. Les plus coûteuses d'abord.
Vos sites interrogés jusqu'à toutes les 30 secondes ; alerte à la panne, au rétablissement et avant l'expiration du certificat.
Une page publique pour vos clients : état de chaque service, 90 jours d'historique, message en cas d'incident.
Crons, jobs et sauvegardes signalent chaque exécution : vous savez quand l'une ne tourne pas, échoue ou dure trop.
CPU, mémoire, disques et charge chaque minute, avec des seuils d'alerte par serveur. Un conteneur à lancer, aucun agent maison.
Vos piles JavaScript minifiées redeviennent lisibles : fichier, ligne et fonction d'origine.
E-mail, Microsoft Teams ou webhook signé, regroupées pour ne pas vous noyer.
Un ticket Azure Boards ou GitHub Issues pour les erreurs qui le méritent : selon le niveau, le nombre d'occurrences, l'environnement ou une régression.
Vos collègues se connectent avec leur compte Microsoft et rejoignent l'organisation sans invitation. Sur tous les plans.
Devbrau parle le protocole des SDK Sentry. Vous gardez votre code d'initialisation, vos breadcrumbs, vos releases.
Choisissez la plateforme ; Devbrau vous donne son DSN.
Sentry.init({ - dsn: "https://3f1c…@o4507.ingest.sentry.io + dsn: "https://9a2e…@/45", ingest.devbrau.fr release: process.env.RELEASE, });/12",
Les premières erreurs arrivent, regroupées en issues.
SDK Testé avec les SDK officiels Node.js et Python. Les autres SDK Sentry (navigateur, Java, PHP, Go, .NET, Ruby) parlent le même protocole.
Tout se vérifie dans l'application, sans écrire au support.
| Contrôle | Chez Devbrau | Comment le vérifier |
|---|---|---|
| Stockage | Événements, logs, métriques, issues et comptes dans l'Union européenne | Engagement du service |
| Analyse IA | Données de l'erreur, et extraits de code au niveau 2, envoyés à Anthropic (Claude), hors de l'UE ; rien au niveau 0 | Réglages du projet et journal des accès au code |
| Données personnelles | E-mails et adresses IP retirés à l'ingestion, avant écriture | Réglage RGPD de chaque projet |
| Isolation | Vos données sont cloisonnées de celles des autres clients | Contrôlé à chaque requête |
| Lecture du code par l'IA | Chaque fichier lu et chaque appel au modèle sont journalisés | Journal des accès au code, exportable |
| Écriture dans vos dépôts | Branches devbrau/* et pull requests uniquement | Votre forge, comme toute PR |
| Niveau d'accès | De 0 à 3, choisi par projet, vérifié côté serveur | Réglages du projet |
Par organisation, hors taxes. Chaque plan est un intervalle de référence : tant que vous y restez, tout fonctionne.
| Mesure | Free | Pro | Team |
|---|---|---|---|
| Prixpar mois | 0 € | 29 € | 99 € |
| Événementspar mois | 0–5 000 | 0–100 000 | 0–1 000 000 |
| Analyses IApar mois | 0–10 | 0–300 | 0–3 000 |
| Correctifs automatiquespar mois | non inclus | 0–30 | 0–300 |
| Rétentionjours | 14 | 90 | 180 |
| Logslignes par mois | 0–50 000 | 0–1 000 000 | 0–10 000 000 |
| Rétention des logsjours | 7 | 30 | 90 |
| Moniteurs (sites et tâches planifiées)sites vérifiés toutes les | 3 · 5 min | 20 · 1 min | 100 · 30 s |
| Serveurs supervisésCPU, mémoire, disque, logs | 1 | 10 | 50 |
| SSO Microsoft Entra IDéquipe rejointe sans invitation | Inclus | Inclus | Inclus |
Hors intervalle Au-delà d'un quota, la fonction se met en pause jusqu'au mois suivant. Aucun dépassement n'est facturé.
Commencez en Free, puis changez de plan depuis la page Abonnement de l'application.