Lighthouse et les scanners notent les pages publiques. Ce que vos clients paient vit derrière la connexion : tableaux de bord, réglages, formulaires.
→ /login
Votre application est un labyrinthe.
Marble Minotaur la parcourt en entier, connexion comprise.
Marble Minotaur se connecte avec un vrai compte, ouvre chaque écran derrière la page de connexion et vous rend, en une vingtaine de minutes pour soixante écrans, la liste triée de ce qui casse, de ce qui menace, et de ce qui tient.
- écrans ouverts en 16 min 58 s
- 60
- vérifications documentées
- 311
- tailles d’écran par page
- 3
- ligne de code à installer
- 0
→ /dashboard(1/60)
Vos utilisateurs trouvent les bugs avant vous.
Pas sur la page d’accueil : derrière la connexion, là où ils travaillent. Un tableau de bord qui charge sans fin, un bouton qui n’appelle plus rien depuis la dernière version, un formulaire illisible sur téléphone. Personne ne l’a vu, parce que personne n’a tout parcouru.
- Ils cliquent, rien ne se passe. clic réel · aucune réaction
- Un chargement ne se termine jamais. squelette encore là après 8 s
- Un écran met 13,9 s à s’afficher. mesuré écran par écran
- Sur mobile, ils tapent à côté. cibles sous 44 px à 375 px
Les audits s’arrêtent à la porte.
Vos tests vérifient ce que vous avez prévu.
Pas l’écran ajouté la semaine dernière, pas la tablette, pas le bouton dont l’appel a changé. Un test ne trouve que ce qu’on a pensé à écrire.
La recette ne passe pas partout.
Soixante écrans en trois tailles à chaque version, c’est des jours. On recette ce qui a changé, pas ce qui s’est cassé à côté.
Les outils automatiques crient au loup.
Mille alertes sans ordre, le même défaut compté trente fois. L’équipe arrête de lire, et le vrai problème passe avec le bruit.
Ce que ça coûte se voit ailleurs : des tickets de support, une démo qui déraille, un audit de sécurité qui tombe la semaine de la signature.
→ angles-morts
Chaque outil voit une partie du labyrinthe.
Marble Minotaur ne remplace ni vos tests, ni votre recette, ni un audit complet : il voit en moins d’une heure ce qu’ils ne voient pas, et vous dit où ils manquent. Il ne lit pas votre code ; ça, c’est le travail d’un audit.
| Pratique | Derrière la connexion | Tous les écrans, sans liste à tenir | Trois tailles d’écran | Chaque appel réseau | Défauts regroupés, corrections ordonnées | Un document à transmettre | Ce qui n’a pas été testé, dit | Le code et le serveur | Un résultat dans l’heure |
|---|---|---|---|---|---|---|---|---|---|
| Un scanner de page (Lighthouse, outils SEO) | non | en partie | en partie | non | en partie | en partie | non | non | oui |
| Vos tests de bout en bout | oui | non | en partie | en partie | non | non | non | non | oui |
| Une recette manuelle | oui | en partie | en partie | non | en partie | en partie | non | non | non |
| Le monitoring en production | oui | en partie | en partie | oui | non | non | non | en partie | oui |
| Un audit par un consultant | oui | en partie | en partie | en partie | oui | oui | en partie | oui | non |
| Marble Minotaur | oui | oui | oui | oui | oui | oui | oui | non | oui |
le voit en partie, ou si quelqu’un y pense ne le voit pas
« Tous les écrans » : jusqu’à la limite que vous fixez. Ce qui reste hors de portée est listé dans le rapport, jamais tu.
→ le-film
Un passage, en une minute et demie.
→ [auth]
Comment se déroule un passage.
Cinq temps, toujours dans cet ordre. Vous n’intervenez qu’au premier.
-
Étape 1 : Vous me donnez une adresse et un compte de test.
Il se connecte comme un utilisateur ordinaire, par le vrai formulaire de connexion. Si la session tombe en route, il se reconnecte et reprend où il en était.
$ npx marble-minotaur https://app.exemple.fr --auth … --forms[auth] Authenticating as test@granit.local...[auth] ✓ Authenticated : landed on /dashboard[crawl] → /dashboard (1/60) ✓ 3568ms 17 links[crawl] → /projects (4/60)[crawl] Session lost before /projects, signing back in[auth] ✓ Authenticated : landed on /dashboard[crawl] → /projects/:id/checks/:id (5/60)[crawl] Loading indicator never cleared after 8052ms ✓ 10662ms 18 links 1 form ⚠ 1 issue -
Étape 2 : Il parcourt l’application, salle par salle.
Il avance en largeur d’abord, et reconnaît les écrans qui se ressemblent :
/projects/42et/projects/73sont la même salle, visitée une fois. Chaque couleur, c’est ce qu’il y a trouvé.Sur l’exemple de ce site, 60 écrans ouverts en 16 min 58 s. L’application auditée, Granit Golem, est un autre de mes projets : passée telle quelle, sans retouche avant ni après.
extrait du film · le labyrinthe des 60 écrans -
Étape 3 : Il vérifie chaque écran sous tous les angles.
311 vérifications rangées en 11 familles : sécurité, accessibilité, performance, expérience, réseau, formulaires, conformité. Chaque écran en trois tailles, chaque appel réseau lu un par un.
1280 · bureau 
768 · tablette 
375 · déborde de 64 px /projects/:id/activity · 5 cibles trop petites pour un doigt
-
Étape 4 : Il trie, relie et ordonne.
Un défaut présent sur trente écrans n’est pas trente tickets : il est dit une fois, avec la liste des écrans touchés. Les défauts qui, ensemble, ouvrent une porte sont reliés en un risque : un en-tête absent et un témoin lisible font un détournement de session.
Puis les corrections sont rangées par ce qu’elles règlent : la plus rentable en premier.
1 013constats relevés66familles à corrigerSur une application plus grande que notre exemple.
-
Étape 5 : Vous recevez un rapport que l’équipe lit.
Un fichier qui s’ouvre sans connexion et se transmet par courriel. Il commence par le verdict, dit quoi ouvrir en premier, et pour chaque défaut ce qu’il rend possible et comment le corriger.
La synthèse du passage d’exemple.
Faire passer le Minotaure chez vous Premier passage offert, relecture comprise.
→ /audits
311 vérifications, expliquées sans jargon.
Chaque vérification est une phrase qu’un chef de projet comprend (« Aucune règle ne limite les scripts autorisés à s’exécuter »), suivie de son nom technique pour l’équipe, d’un exemple, du risque et de la piste de correction.
Réseau 61 Les appels entre le navigateur et le serveur : nombre, poids, réponses. Sécurité 53 Ce qui protège les données et les sessions contre un tiers. Performance 49 Le temps que la page met à s’afficher et à répondre. Accessibilité 31 Ce qui permet à chacun de lire et de commander la page, aides techniques comprises. Stabilité 26 Ce qui tient sous une panne, un rechargement ou un lien ouvert directement. Qualité 23 La tenue générale : textes, images, liens, cohérence d’un écran à l’autre. Expérience 19 Ce que la personne voit et touche : tailles d’écran, gestes, zones cliquables. Référencement 18 Ce que les moteurs de recherche comprennent de la page. Gouvernance 16 Le consentement, les mentions et les règles que l’application doit tenir. Socle technique 8 Les composants, versions et outils que la page embarque. Formulaires 7 Ce que les formulaires demandent, vérifient et répondent.
→ /projects/:id/components/new
Ce que subissent vos utilisateurs, en chiffres.
Des mesures relevées pendant le passage, comparées à un seuil. Ce qui tient est dit aussi clairement que ce qui casse.
4,7× le seuil 236ms pendant lesquelles la page ne répond plus au clic
à surveiller 4,9Mo de JavaScript téléchargés à la première visite
à surveiller 12/60 écrans qui débordent sur un téléphone
dans le seuil 5ms pour la première réponse du serveur
dans le seuil 0,000 de décalage visuel au chargement
→ marble-report.html
Tout tient dans un seul fichier.
Un compte rendu d’expertise, pas un tableau de bord : il se lit de haut en bas, se transmet, s’imprime.
Écrit pour l’équipe
Chaque défaut est une phrase en clair ; le nom technique vient après, pour qui en a besoin.
Trié par ce qui compte
Maintenant, ensuite, quand ce sera réglé. Chaque correction dit combien d’écrans elle répare.
Il dit ce qui tient
Les fonctions vues fonctionner, les vérifications passées, la plateforme reconnue : pas seulement les défauts.
Honnête sur ses limites
Ce qui n’a pas été testé est écrit comme tel, jamais compté comme une réussite. Nos pannes ne vous sont jamais imputées.
observé sur ce passage déduit de ce qui a été vu non testé, et dit
→ --probesur demande
Il entre chez vous. Voici ce qu’il s’interdit.
- Aucun accès au code
- Tout se fait de l’extérieur, comme un utilisateur. Rien à installer, aucun framework imposé.
- Lecture seule par défaut
- Il ouvre, regarde et mesure. Cliquer les boutons ou soumettre les formulaires ne se fait que si vous l’autorisez.
- Jamais de suppression
- Aucune requête de suppression n’est émise, quel que soit le réglage. Un libellé comme « Supprimer » ou « Résilier » n’est jamais cliqué.
- Pas de compte créé à votre insu
- Les formulaires d’inscription sont reconnus et laissés de côté, sauf demande explicite.
- Un budget borné
- Nombre d’écrans, durée et parcours rejoués sont plafonnés. Il s’arrête quand on le lui dit, et écrit ce qu’il n’a pas vu.
→ /votre-application
Dans quels cas le faire passer.
Avant une mise en production
La version part vendredi. Les tests sont verts, la recette a vu les nouveautés. Personne n’a rouvert les quarante écrans qui n’ont pas changé.
Vous repartez avec la liste de ce qui casse, rangée par urgence, et ce que vos tests n’ont pas couvert.
Avant de racheter ou de reprendre une application
Vous héritez d’un produit que vous n’avez pas construit. Avant de lire la première ligne de code, sachez ce qu’il permet vraiment et ce qui y menace.
Vous repartez avec un état des lieux indépendant, écran par écran, opposable au vendeur ou au prestataire sortant.
Pour livrer à un client
Agence ou prestataire, vous remettez une application. Le rapport prouve ce qui a été vérifié, et sur quoi.
Vous repartez avec un document qui se lit sans vous et qui dit ce qui tient autant que ce qui casse.
Pour suivre une application dans le temps
Deux passages se comparent : fonctions perdues, parcours qui ne s’enchaînent plus, constats résolus.
Vous repartez avec ce qui est apparu, disparu ou s’est dégradé d’une version à l’autre.
→ /a-propos
Fait par quelqu’un qui fait des audits.
Je suis Cédric, architecte Web et API chez siliceum, à Nantes. Marble Minotaur automatise ce que je vérifie à la main depuis dix ans quand on me confie une application que je ne connais pas. Je le construis seul, et je lis chaque rapport qu’il produit pour vous.
Cédric Chariere Fiedler Président et directeur technique Architecte Web et API : fiabilité, performance, QA Nantes
siliceum a travaillé pour : Asobo Studio · Euromaster · Michelin · Arturia · CAE · Limagrain
→ questions
Ce qu’on me demande avant un premier passage.
Faut-il installer quelque chose dans notre application ?
Non. Marble Minotaur travaille de l’extérieur, depuis un vrai navigateur, comme un utilisateur. Aucun script à ajouter, aucun accès au code, aucun framework imposé : Vue, React, Angular, Laravel ou rendu serveur, il voit la même chose que vos utilisateurs.
Combien de temps dure un passage ?
Sur notre exemple, 60 écrans ont été ouverts en 16 min 58 s. Le rapport est prêt à la fin du passage ; je le relis avant de vous l’envoyer, puis nous le lisons ensemble une demi-heure.
Est-ce risqué pour nos données ?
Par défaut, il ne fait que lire : il ouvre, regarde et mesure. Les clics réels et les formulaires ne sont joués que si vous les autorisez, et aucune requête de suppression n’est jamais émise. Je recommande un environnement de préproduction et un compte de test dédié, transmis à part, jamais par courriel.
Que contient le rapport, et peut-on le partager ?
Un fichier HTML autonome, qui s’ouvre sans connexion : verdict, risques, plan d’action, écrans, fonctions, mesures. Il peut contenir des en-têtes HTTP et des captures de votre application ; une version allégée retire en-têtes, réponses et captures avant de le faire circuler.
En quoi est-ce différent d’un Lighthouse ou d’un scanner SEO ?
Ces outils notent une page publique à la fois. Marble Minotaur se connecte, parcourt toute l’application, croise ce qu’il voit d’un écran à l’autre (forme des appels, gabarits, cohérence) et regroupe les défauts répétés en corrections. Il dit aussi ce qui tient, et ce qu’il n’a pas pu tester.
Est-ce que ça remplace nos tests ou notre recette ?
Non : il les éclaire. Il trouve ce que personne n’a pensé à tester, et sa carte des fonctions observées dit où vos tests de bout en bout manquent. On peut le relancer à chaque version et comparer deux passages.
Combien ça coûte ?
Les premiers passages sont offerts, en échange de votre retour sur le rapport. Ensuite, un passage se chiffre selon la taille de l’application et le périmètre (lecture seule, formulaires, sondes actives). Écrivez-moi, la réponse est rapide.
Notre application utilise une double authentification ou un SSO. Ça marche ?
La connexion par formulaire est détectée seule. Une double authentification ou un SSO demandent un réglage : le plus souvent un compte de test sans second facteur, ou une session préparée à la main avant le passage.
Qui voit nos données ?
Moi seul. Le rapport vous est remis et n’est pas fait pour être conservé ; un accord de confidentialité peut être signé avant le passage si vous le souhaitez.
Peut-on le lancer nous-mêmes ?
Pas encore en libre-service : pour l’instant, je lance chaque passage et je relis chaque rapport. C’est aussi ce qui permet de corriger un faux positif avant qu’il n’arrive chez vous.
Le rapport est-il disponible en anglais ?
Pas encore : le rapport est rédigé en français. La lecture commune peut se faire en anglais.
→ 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.