Exemple de livrable

Exemple de rapport d’audit d’une application créée avec l’IA

Voici, à l’identique dans sa forme, ce que vous recevez à l’issue d’un diagnostic. Chaque constat dit ce qui a été observé, ce que ça risque concrètement, comment le corriger et combien de temps ça prend.

Projet fictif. Ce rapport ne concerne aucun client réel : il rassemble des constats que l’on retrouve très souvent dans les projets générés par IA. Les rapports de mes clients restent confidentiels.

1. Le projet audité

Application
Réservation et paiement de cours pour une école de sport nautique
Construite avec
Lovable, code synchronisé sur GitHub
Technologies
React, Supabase (base, connexion, fichiers), Stripe Checkout
Situation
Bêta privée, environ 120 utilisateurs, ouverture au public prévue
Périmètre
Code, base de données, configuration, parcours inscription, réservation et paiement
Méthode
Lecture du code, tests manuels des accès, analyse de la configuration et des performances

2. Synthèse

Ouverture au public déconseillée en l’état. Les deux points bloquants se corrigent en moins de deux jours.

L’application est bien conçue du point de vue de l’utilisateur et sa base de données est saine : il n’y a aucune raison de la reconstruire. En revanche, les données des clients sont aujourd’hui accessibles sans connexion, et le lien entre paiement et réservation n’est pas fiable. Ces deux points doivent être traités avant toute ouverture. Le reste relève de l’amélioration et peut être étalé.

Note par domaine (sur 5)

  • Sécurité1/5
  • Paiement2/5
  • Données2/5
  • Fiabilité3/5
  • Maintenabilité3/5
  • Conformité3/5
  • Performance4/5

Ce qui est solide

  • Interface claire et cohérente : le parcours de réservation est compris sans explication.
  • Connexion des utilisateurs bien configurée (confirmation par email, mots de passe gérés par Supabase Auth).
  • La clé secrète Stripe est correctement conservée côté serveur.
  • Structure des tables globalement saine : pas de refonte des données nécessaire.

3. Constats détaillés

Classés par gravité. L’effort indiqué est une estimation pour la correction, tests compris.

  1. C1CritiqueSécuritéEffort : ½ journée

    Les réservations de tous les clients sont lisibles sans connexion

    Constat :
    Les règles d’accès (RLS) sont désactivées sur les tables « reservations » et « profiles ». Une requête envoyée avec la clé publique du site, sans être connecté, renvoie l’ensemble des réservations : noms, téléphones, dates.
    Risque :
    N’importe qui peut télécharger la liste complète de vos clients. Si quelqu’un le fait, c’est une violation de données personnelles, qui doit en principe être notifiée à la CNIL dans les 72 heures.
    Correction :
    Activer RLS sur toutes les tables, écrire des règles qui limitent chaque utilisateur à ses propres lignes, réserver l’accès global à un rôle administrateur vérifié côté base.
  2. C2CritiquePaiementEffort : 1 journée

    Une réservation peut être payée sans être enregistrée, ou enregistrée sans être payée

    Constat :
    La réservation est créée par le navigateur lorsque le client revient sur la page « /success » après Stripe. Cette page peut aussi être ouverte directement, sans paiement.
    Risque :
    Si le client ferme l’onglet après avoir payé, l’argent est encaissé mais la réservation n’existe pas. À l’inverse, une personne avertie peut réserver gratuitement.
    Correction :
    Créer la réservation uniquement à réception du webhook Stripe « checkout.session.completed », avec vérification de signature, et ignorer un événement déjà traité.
  3. E1ÉlevéSécuritéEffort : 2 heures

    L’export administrateur est accessible à tout utilisateur connecté

    Constat :
    Le bouton d’export CSV n’est affiché qu’aux administrateurs, mais la fonction serveur qui génère le fichier ne vérifie pas le rôle de l’appelant.
    Risque :
    Un client connecté peut appeler la fonction directement et récupérer le fichier complet.
    Correction :
    Vérifier le rôle administrateur dans la fonction serveur, avant toute lecture de données.
  4. E2ÉlevéDonnéesEffort : ½ journée

    Aucune sauvegarde restaurable

    Constat :
    L’offre actuelle de la base de données ne fournit pas de sauvegarde accessible, et aucun export planifié n’existe.
    Risque :
    Une suppression accidentelle (par vous, par un bug ou par une modification de l’IA) est définitive.
    Correction :
    Mettre en place des sauvegardes quotidiennes, puis faire un essai de restauration sur un projet de test.
  5. M1MoyenMaintenabilitéEffort : 1 journée

    Trois versions du calcul de prix coexistent

    Constat :
    Le calcul du tarif d’une réservation existe en trois exemplaires, dont deux ne sont plus utilisés. Le formulaire de réservation fait 1 400 lignes dans un seul fichier.
    Risque :
    Les corrections sont appliquées au mauvais endroit, ce qui explique les bugs « corrigés » qui reviennent. Chaque modification demandée à l’IA devient plus risquée.
    Correction :
    Supprimer le code mort, centraliser le calcul du prix, découper le formulaire en composants, ajouter un test sur le calcul.
  6. M2MoyenFiabilitéEffort : 2 heures

    Les erreurs ne remontent nulle part

    Constat :
    Les erreurs sont uniquement écrites dans la console du navigateur de l’utilisateur. Aucun outil de suivi n’est en place.
    Risque :
    Les pannes sont découvertes par les clients, pas par vous.
    Correction :
    Installer un outil de suivi des erreurs avec alerte par email, et afficher des messages clairs à l’utilisateur.
  7. M3MoyenConformitéEffort : ½ journée

    Traceurs sans consentement et données collectées inutilement

    Constat :
    Google Analytics se charge avant tout consentement. Le formulaire demande une date de naissance qui n’est utilisée nulle part. Pas de politique de confidentialité.
    Risque :
    Non-conformité au RGPD et aux recommandations de la CNIL sur les traceurs, et perte de confiance des visiteurs attentifs.
    Correction :
    Ajouter un bandeau de consentement, supprimer le champ inutile, rédiger la politique de confidentialité.
  8. F1FaiblePerformanceEffort : 2 heures

    Chargement lent sur mobile

    Constat :
    Les photos de la page d’accueil pèsent 3 à 4 Mo chacune. Le contenu principal met environ 4 secondes à s’afficher sur un mobile en 4G.
    Risque :
    Une partie des visiteurs mobiles repart avant d’avoir vu l’offre.
    Correction :
    Compresser et redimensionner les images, les servir dans un format moderne (WebP ou AVIF).

4. Plan d’action recommandé

  1. Étape 1 : Avant l’ouverture au public

    Constats C1, C2, E1, E2 (environ 2,5 jours)

  2. Étape 2 : Dans les deux semaines suivantes

    Constats M2, M3, F1 (environ 1 jour)

  3. Étape 3 : Avant d’ajouter de nouvelles fonctionnalités

    Constats M1 (environ 1 jour)

Chiffrage. L’étape 1 correspond à la formule Sécurisation (à partir de 890 €). L’ensemble du plan correspond au bas de la fourchette de la formule Mise en production (1 900 à 4 500 €). Le prix exact est fixé avant de commencer, et le diagnostic (290 €) est déduit si vous poursuivez. Chaque correction peut aussi être réalisée par vos soins ou par un autre prestataire : le rapport est écrit pour ça.

Le même rapport, pour votre projet

Rapport sous 5 jours ouvrés, 30 minutes d’échange pour tout expliquer, 290 €. Commencez par me décrire votre projet : je vous dis si un diagnostic est utile, ou si la version gratuite en 10 questions suffit pour l’instant.

Décrire mon projet Voir les formules