Aller au contenu
Aeria
Décrire mon projet

Reprise d'app vibe-codée

Votre app vibe-codée,au standard, preuve à l'appui.

Lovable, Bolt, v0, Cursor, Replit : la démo marche, les vrais utilisateurs arrivent. Nous lisons le code, le mettons aux huit articles du standard ci-dessous et vous le rendons avec ce qui le prouve. Vous pouvez nous opposer la liste.

Envoyer le repoLire le standard

Lecture seule. Vous gardez le dépôt et les comptes.

Nos règles

  • lecture seule
  • on évalue avant de toucher
  • aucun correctif sans votre accord

Le rapport de reprise

  1. Synthèse
  2. Constats par gravité
  3. Preuve
  4. Correctif
  5. Décision garder / refactorer / reconstruire
rapport de reprise · exemple

Aucun exemple public pour l'instant. Cet emplacement reste vide tant qu'un propriétaire n'a pas consenti à la publication de son rapport.

Ce qui casse

Ce qui casse vraiment

Si trois de ces lignes vous parlent, la reprise est pour vous. Si votre app n'a pas encore d'utilisateurs, ce n'est sans doute pas le bon moment — voir « Pour qui ».

Ça fuit

Un utilisateur m'a écrit qu'il voyait les données d'un autre.
Pas de vérification de propriété côté serveur : on lit l'objet d'autrui en changeant un identifiant.
Art. 02
N'importe qui peut lire ma base depuis son navigateur.
Clé publique + aucune règle de ligne (RLS) : lecture et écriture ouvertes à tous.
Art. 02
Une clé d'API est visible dans l'inspecteur du navigateur.
Un secret est embarqué dans le bundle au lieu de rester côté serveur.
Art. 06
Un statut « payé » peut être posé depuis le navigateur.
L'état de facturation est écrit par le client, pas par le serveur.
Art. 01

Ça casse

Le paiement passe… parfois deux fois.
Webhook sans vérification de signature ni idempotence : un renvoi crée un doublon.
Art. 07
La connexion marche, puis déconnecte sans raison.
Gestion de session fragile, pas de limitation des tentatives.
Art. 01
Chaque nouvelle fonctionnalité en casse deux anciennes.
Aucun test ne verrouille le comportement attendu ; pas de CI pour l'attraper.
Art. 03
Quand ça plante, je l'apprends par un client.
Erreurs avalées, aucun journal exploitable, aucune alerte.
Art. 07

Plus personne n'y touche

Je n'ose plus redemander une modif à l'IA.
Elle a déjà réintroduit un bug ; rien ne protège contre la régression.
Art. 05
Il n'y a qu'un seul environnement : je teste en prod.
Pas de séparation dev/prod ; un essai touche les vraies données.
Art. 03
Le code importe un paquet que personne ne reconnaît.
Dépendance inventée par le modèle, jamais vérifiée (chaîne d'approvisionnement).
Art. 06
J'ai une échéance et je n'ose pas ouvrir le capot.
Démo client, levée ou audit : personne ne sait ce que l'app tient vraiment.
Art. 05

La reprise

Comment ça se passe

Fig. 01 · La reprise, station par station

Une ligne part de votre app telle quelle, passe par un audit en lecture seule qui produit un rapport classé par gravité, s'arrête à une porte — votre accord — puis la mise au standard, une PR par sujet relue, et se termine par la remise : tests, CI, documentation et preuves, à vous.

  1. Votre app

    Un échange, le lien du dépôt ou de l'app. Rien à installer, rien à préparer.

    Un premier avis franc

  2. Audit

    Nous lisons le code, le schéma et la configuration en lecture seule ; aucune écriture, aucun secret recopié. Les constats sont classés par gravité, rattachés au standard, avec la preuve et le correctif proposé.

    Le rapport de reprise

  3. Mise au standard

    Corrections par ordre de gravité, une PR par sujet, relues. Rien n'est fusionné sans votre accord, vous gardez le contrôle du dépôt.

    Des PR relisables

  4. Remise

    Tests, CI, documentation, preuves liées. Vous — ou votre prochain dev — pouvez continuer sans nous.

    Un code que vous possédez

Durée et prix sont fixés par écrit après la lecture du dépôt, avant tout travail. Pas de grille, pas de facture surprise.

Le standard

Huit articles.Opposables.

Huit articles, publics. Les quatre premiers sont ceux qui lâchent en premier dans une app vibe-codée. Les quatre suivants la rendent maintenable.

registre ouvert

0 / 8 articles ont un reçu public

Les quatre verrous — le même standard que la maison

Les quatre verrous

  • Authentification et 2FA

    pas encore

    Chaque route exige une session valide ; le contrôle d'accès est vérifié côté serveur, et la 2FA est disponible pour les comptes sensibles.

    ÉlevéeVérifié par · Revue du flux, reset, expiration ; champs rôle/paiement côté serveur

    Aucun reçu public pour l'instantLa réponse

  • Données : RLS par compte

    pas encore

    Chaque table exposée a une règle d'accès correcte, pas seulement présente ; un utilisateur ne lit et n'écrit que ses propres données.

    CritiqueVérifié par · Requêtes avec la clé publique + test d'isolation entre comptes · Lecture/écriture d'un objet d'un autre compte, route par route

    Aucun reçu public pour l'instantLa réponse

  • Pipeline : CI verte

    pas encore

    Un pipeline lance types, lint et tests à chaque changement ; rien n'atteint la production sans passer au vert.

    ÉlevéeVérifié par · On casse un test exprès : la CI doit échouer · Dev/prod séparés, déploiement reproductible, retour arrière

    Aucun reçu public pour l'instantLa réponse

  • En-têtes de sécurité

    pas encore

    Les en-têtes de sécurité (CSP, HSTS, type de contenu, cadre, référent) sont posés et vérifiés sur le déploiement réel.

    ÉlevéeVérifié par · Scan des en-têtes (CSP, HSTS, type de contenu, cadre, référent) sur l'URL de production, pas sur la préversion

    Aucun reçu public pour l'instantLa réponse

Maintenabilité

  • Types stricts et tests

    pas encore

    TypeScript strict aux frontières ; les parcours à risque (accès, paiement) sont couverts par des tests qui échouent quand le comportement casse.

    ÉlevéeVérifié par · Couverture des parcours d'accès et d'argent d'abord · Validation côté serveur, encodage en sortie (XSS, injection)

    Aucun reçu public pour l'instant

  • Secrets et dépendances

    pas encore

    Aucun secret dans le bundle, le dépôt ou l'historique git ; les dépendances sont auditées et chaque paquet existe réellement.

    CritiqueVérifié par · Inspection du bundle livré et de l'historique git · Secrets hors dépôt, rotation possible, dev/prod séparés · Revue des droits d'écriture donnés aux outils IA · Audit du lockfile, vérification des noms de paquets

    Aucun reçu public pour l'instant

  • Erreurs gérées et observabilité

    pas encore

    Les échecs attendus sont gérés, les inattendus journalisés et alertés ; il existe un endroit où regarder quand ça casse.

    CritiqueVérifié par · Rejeu d'un webhook : un événement, un seul effet · On provoque une panne : trace exploitable et alerte

    Aucun reçu public pour l'instant

  • Sortie propre de la plateforme

    pas encore

    Le dépôt vous appartient, le déploiement est documenté et reproductible ; aucune dépendance cachée à la plateforme d'origine.

    MoyenneVérifié par · Restauration testée au moins une fois, migrations versionnées

    Aucun reçu public pour l'instant
0 / 8 articles ont un reçu public0 / 8

Passer les huit articles ne prouve pas que votre app est sûre ; cela prouve que ces huit contrôles passent.

Gravité. Critique = exploitable aujourd'hui par un inconnu. Élevée = bloque la croissance ou casse sous charge. Moyenne = dette qui coûtera plus tard.

Ces huit articles sont la liste. Une reprise les vise tous, article par article — et cette page dit lesquels sont déjà prouvés.

Documents publics

  • Rapport de reprise · exemplenon publié
  • Dépôt de démonstrationnon publié
  • Captures avant / aprèsnon publié

publié à la demande du propriétaire

La décision

Garder, refactorer ou reconstruire

Fig. 02 · La règle

Une porte pose la question : le modèle de données tient-il ? S'il tient, on répare. S'il tient mais que tout est mêlé, on refactore. S'il se contredit, on reconstruit. Aucune branche n'est favorisée ; la réponse vient de la lecture.

  • Réparer

    Le modèle de données est sain, les écrans sont à garder : on ferme les trous et on ajoute les filets (tests, CI, alertes).

  • Refactorer

    La logique et les droits sont mêlés à l'affichage : on sépare d'abord, puis on répare. Le résultat se maintient.

  • Reconstruire

    Le modèle de données se contredit, ou plus personne ne sait ce que fait l'app : chaque correctif coûte plus que la reconstruction.

La règle : le modèle de données est le seuil. S'il tient, on répare autour. Sinon, on vous le dit.

Si reconstruire coûte moins cher que réparer, nous vous le dirons — même si le devis est plus petit pour nous.

Pour qui

Pour qui, et pour qui pas

C'est pour vous si

  • votre app a de vrais utilisateurs, ou un lancement proche
  • elle gère des données personnelles ou des paiements
  • vous voulez savoir la vérité avant de dépenser
  • vous voulez garder la propriété du code
  • vous acceptez un « reconstruisez » comme réponse possible

Ce n'est pas pour vous si

  • vous n'avez pas encore d'utilisateurs (la plateforme suffit encore)
  • vous cherchez le devis le moins cher plutôt que l'avis le plus franc
  • vous voulez une certification de conformité (nous ne la délivrons pas)
  • vous voulez ajouter des fonctionnalités avant de corriger les failles

Questions

Questions franches

Pas par défaut. Le rapport tranche garder, refactorer ou reconstruire, avec la raison. Le seuil, c'est le modèle de données.

Non pour commencer : lecture seule du dépôt et de l'app. Si une correction l'exige, c'est sur une branche, avec votre accord, et l'accès est révocable.

À vous, en totalité : dépôt, comptes, base, clés. Nous travaillons dans vos comptes ou un fork qui vous appartient.

Oui, si vous le souhaitez, avant d'ouvrir quoi que ce soit. Envoyez le vôtre ou demandez le nôtre.

Le budget et le délai sont donnés par écrit après la lecture du dépôt, avant tout travail. Ils dépendent de ce qui casse, pas d'une grille. Pas de tarif affiché ici.

Pas par principe. On durcit en place ou on reprend le code en dehors, après lecture. Ce qui compte : que le code et les comptes soient à vous.

Gardez ces scans : ceux de Lovable ou de Supabase existent et sont utiles. Leur documentation le dit elle-même : ils ne peuvent pas garantir une sécurité complète. Un scan vérifie qu'une règle existe ; nous lisons le code et testons qu'elle est juste, en essayant de lire ce que nous ne devrions pas. La page sécurité de Lovable (s'ouvre dans un nouvel onglet)

Envoyer le repo

Montrez-nous l'app.On lit d'abord, on ne vend pas.

La démo marchait. Voyons où elle en est par rapport aux huit articles. Un lien et une adresse suffisent ; nous lisons avant de proposer quoi que ce soit.

GitHub, GitLab ou l'adresse publique de l'app. « owner/repo » suffit.

Construite avec

Plusieurs choix possibles.

Ce qui casse (optionnel)

Cochez ce qui vous parle ; les détails viennent en dessous.

Ce que vous avez observé, en quelques lignes.

Le prénom suffit.

Nous répondons à cette adresse.

Votre client mail s'ouvre avec le brouillon. Rien n'est envoyé depuis cette page.

Et ensuite

  1. Le brouillon s'ouvre dans votre client mail ; rien ne part de cette page.

  2. Nous répondons par e-mail avec un premier avis franc.

  3. Accès lecture seule : collaborateur GitHub en lecture, ou une archive zip. Nous ne demandons jamais de clé service-role, d'identifiant de prod ni de fichier .env.

Vous préférez en parler avant d'envoyer quoi que ce soit ?

Décrire mon projet

Ou écrivez-nous directement : hello@aerialabs.com