Chaque affirmation du rapport dit d’où elle vient. Ce qui a été vu n’est jamais mélangé avec ce qui a été supposé, et ce qui n’a pas été testé est écrit comme tel.
→ /a-propos
Un auditeur qui en avait assez de tout refaire à la main.
Marble Minotaur est construit par une seule personne, au sein de siliceum, un cabinet d’ingénierie qui rend fiables, rapides et observables des systèmes dont une entreprise dépend.
→ pourquoi
Pourquoi Marble Minotaur.
Quand on me confie une application que je ne connais pas, les premiers jours se ressemblent toujours. Je crée un compte, j’ouvre chaque écran, je regarde les en-têtes, les temps de réponse, les formulaires, le téléphone, la console. Je note ce qui casse, je regroupe ce qui se répète, je remonte ce qui menace. C’est utile, c’est long, et c’est exactement le même travail d’un client à l’autre.
Marble Minotaur fait ces premiers jours en vingt minutes, et les fait mieux sur un point : il n’oublie aucun écran. Il me rend le temps de faire ce qu’un outil ne fait pas : comprendre pourquoi, et accompagner la correction.
Je l’ai construit pour mes missions. Je le propose maintenant aux équipes qui veulent ce premier regard sans attendre une mission complète.
→ qui
Une personne, dix ans d’audits.
Cédric Chariere Fiedler Président et directeur technique Architecte Web et API : fiabilité, performance, QA Nantes
Architecte Web et API depuis plus de dix ans, je conçois et fiabilise des plateformes exigeantes : qualité, performance, maintenabilité.
Tests dirigés par le risque, observabilité, tests de charge, résilience : le regard que Marble Minotaur porte sur une application est celui que je porte en mission.
→ missions
Ce que j’ai fait ailleurs.
Des missions siliceum où j’intervenais, et où la fiabilité et la performance se mesuraient, avant et après.
Asobo Studio · Flight Simulator 2024 60 fps tenus sur les écrans critiques
Menus et cockpits sont des interfaces web embarquées dans le moteur : chargements divisés par 2 à 10, sans réécriture.
Euromaster −92 % de latence au 99ᵉ centile
2,3 s ramenées à 180 ms sur les appels critiques d’une suite B2B européenne, migrée sans coupure dans 5 pays.
Scale-up SaaS B2B ÷6 tickets de support par mois
De 180 à 30 tickets mensuels, en traitant les incidents récurrents un par un et en outillant l’équipe.
siliceum a travaillé pour : Asobo Studio · Euromaster · Michelin · Arturia · CAE · Limagrain
→ méthode
Six règles, respectées dans chaque rapport.
Un rapport d’audit engage : il dit à des gens que leur travail a des défauts. Ces règles sont vérifiées par des tests dans le code de l’outil.
Observé, déduit, non testé
Jamais de note sur 100
Une note agrège des choses qui ne s’additionnent pas et donne envie de la faire monter plutôt que de corriger. Le rapport dit sain, dégradé, en échec, incomplet ou inconnu.
Mes pannes ne sont pas les vôtres
Si le navigateur de l’outil plante ou qu’un garde-fou l’arrête, c’est écrit comme sa limite, jamais imputé à l’application auditée.
Un fait de l’application est dit une fois
Un défaut présent sur presque tous les écrans relève du socle, pas de chaque écran : une ligne, une correction.
Aucune route inventée
Une destination jamais observée n’est jamais dessinée. Quand un modèle de langage nomme les fonctions, tout ce qu’il cite sans l’avoir vu est retiré.
Écrit pour ceux qui ont construit
Le rapport dit à une équipe que son travail a des défauts. Il le dit en clair, avec la preuve et la correction, et il dit aussi ce qui tient.
→ limites
Ce qu’il ne sait pas faire, dit d’emblée.
- Boîte noire
- Ce qui ne se voit pas depuis un navigateur n’est pas audité : la base de données, le code serveur, l’infrastructure. C’est un autre audit, que siliceum fait aussi.
- Connexion inhabituelle
- La détection du formulaire de connexion est heuristique. Une double authentification ou un parcours exotique demandent un réglage, parfois une session préparée à la main.
- Signaux bruités
- Quelques vérifications sont sensibles à la technologie employée ; elles sont marquées comme telles dans le rapport et demandent une relecture humaine.
- Lecture par un modèle de langage
- Optionnelle et non déterministe. Elle ne nomme que ce qui a été observé ; elle ne décide ni de la gravité ni de la santé d’un parcours.
→ données
Vos données, pendant et après le passage.
- Préproduction de préférence
- Je recommande un environnement de préproduction et un compte de test dédié, aux droits d’un utilisateur ordinaire.
- Ce que contient un rapport
- Des en-têtes HTTP, des extraits de réponses et des captures d’écran. Il vous est remis ; il n’est pas fait pour être stocké durablement.
- Une version allégée
- Pour le faire circuler, une version allégée retire en-têtes, réponses et captures.
→ sortie
Il entre là où les autres s’arrêtent.
Le voyage ne s’active que sur demande. Envoyez-moi trois choses, vous recevez le rapport.
- L’adresse de l’application, en préproduction de préférence
- Un compte de test, avec les droits d’un utilisateur ordinaire
- Le périmètre lecture seule, ou formulaires et clics autorisés
Ce qui se passe ensuite
- Vous m’écrivez l’adresse et le périmètre. Le compte de test arrive à part, jamais dans le courriel.
- Je lance le passage et je relis le rapport avant de vous l’envoyer.
- On le lit ensemble, une demi-heure en visio, pour que votre équipe sache par où commencer.
Les premiers passages sont offerts, relecture comprise, aux équipes qui acceptent de me dire ensuite ce qui leur a manqué dans le rapport.