# Audit de l'état d'un MVP

Réalise cet audit en suivant les consignes ci-dessous. Le rapport sera envoyé à Talyco, qui en tirera un diagnostic de mise en production.

## Consignes pour l'assistant

Tu réalises l'audit d'un outil construit en grande partie avec l'IA, avant sa mise en production. Le but est de mesurer l'état réel du code, des données, de l'infrastructure et de la sécurité. Sois factuel et franc. Un constat désagréable vaut mieux qu'un rapport rassurant.

**Lecture seule**

- Ne modifie, ne déplace et ne supprime aucun fichier. Le seul fichier que tu crées est le rapport, `audit-mvp-rapport.md`, à la racine du dossier, sans le committer.
- Ne fais ni commit, ni push, ni installation de dépendances, ni migration, ni déploiement.
- N'utilise jamais les identifiants trouvés dans le code ou dans un fichier `.env` pour te connecter à un service, même en lecture.
- Ne lance aucune commande qui touche à une base de données, à un service en ligne ou à des données réelles. En cas de doute, demande avant.
- Les commandes de lecture sont permises : lister, compter, chercher, lire, `git log`, `git status`, `git remote -v`. `npm audit` est permis s'il ne demande aucune installation.

**Confidentialité**

- Aucun secret dans le rapport, ni en entier ni en partie. Pour une clé, un mot de passe ou un jeton, indique le fichier et la ligne, le type de secret (le préfixe suffit : `sk_live_`, `service_role`, `ghp_`) et s'il est exposé.
- Aucune donnée personnelle dans le rapport : ni nom, ni e-mail, ni téléphone, ni adresse d'une personne réelle. Si des données réelles sont présentes dans le dépôt (exports, fichiers de test, captures), indique le fichier et le type de données, sans les recopier.
- Pour les auteurs du dépôt, donne leur nombre, pas leurs adresses e-mail.
- Avant d'enregistrer le rapport, relis-le en entier pour vérifier qu'il ne contient ni secret ni donnée personnelle.

**Méthode**

- Réponds à toutes les questions de la partie A. Si une question ne s'applique pas, écris « Sans objet » et pourquoi.
- Pose les questions de la partie B à la personne qui t'utilise, en un seul bloc, et reporte ses réponses dans le rapport.
- Marque chaque réponse d'une étiquette. **[Vérifié]** : lu dans le code ou la configuration. **[Déduit]** : conclusion probable, à confirmer. **[Déclaré]** : dit par la personne. **[Inconnu]** : impossible à savoir d'ici.
- Cite tes preuves avec le chemin du fichier et la ligne, par exemple `src/lib/supabase.ts:12`.
- Si le dépôt est trop gros pour tout lire, échantillonne, et dis ce que tu n'as pas lu.
- Rédige le rapport en français, au format de la partie D.

## Partie A : ce que l'assistant cherche dans le code

### A1. Vue d'ensemble

- Ce que fait l'outil, en cinq lignes, d'après le code.
- Les parcours principaux : écrans, pages ou routes, et ce que l'utilisateur y fait.
- Les rôles d'utilisateurs prévus (administrateur, salarié, client…) et ce que chacun peut faire.
- La plateforme d'origine. Cherche les traces de Lovable (`lovable-tagger` dans `package.json`, mentions dans le README), Bolt (`.bolt/`), Replit (`.replit`, `replit.nix`), v0, Base44, Cursor (`.cursorrules`, `.cursor/`), Claude Code (`CLAUDE.md`), Codex (`AGENTS.md`), et les autres fichiers d'instructions pour IA.
- L'historique : date du premier et du dernier commit, nombre de commits, nombre d'auteurs, rythme des modifications sur les trois derniers mois.
- Les messages de commit : explicites, génériques (« update », « fix ») ou générés automatiquement par la plateforme.

### A2. Dépôt et organisation du code

- Où vit le code : GitHub, GitLab, autre. Sur un compte personnel ou une organisation, d'après `git remote -v`, sans recopier un jeton éventuellement présent dans l'adresse.
- Le nombre de dépôts et le rôle de chacun.
- Les branches : principale, de travail, anciennes. Les tags ou versions publiées.
- Les règles de travail visibles : modèles de pull request, dossier `.github/`, intégration continue.
- L'arborescence sur deux niveaux, avec le rôle de chaque dossier.
- Le nombre de fichiers par type et le nombre de lignes par langage, sans `node_modules`, les dossiers de build ni les fichiers de verrouillage.
- Les dix fichiers les plus longs, avec leur nombre de lignes.
- Les fichiers suspects : copies (`-old`, `copy`, `v2`, `backup`), fichiers vides, gros blocs de code commenté, fichiers jamais importés.
- Le `.gitignore` : ce qu'il exclut, et ce qui est commité alors qu'il ne devrait pas l'être (`.env`, builds, exports de données, `node_modules`).
- La documentation : README, guides, schémas. Ce qu'elle permet vraiment de faire (installer, lancer, déployer).

### A3. Technologies

- Les langages et leurs versions.
- Les frameworks, front et back, avec leurs versions (React, Vite, Next.js, Vue, Express…).
- Les bibliothèques d'interface (Tailwind, shadcn/ui, MUI…).
- Le gestionnaire de paquets, et la présence d'un fichier de verrouillage.
- Les dépendances : nombre de dépendances directes et de développement, les principales avec leur rôle, celles qui sont obsolètes, abandonnées ou inutilisées.
- Les vulnérabilités connues des dépendances (`npm audit` ou équivalent) : nombre par gravité, et les plus graves.
- Les services tiers appelés : authentification, base de données, paiement, e-mail, SMS, stockage de fichiers, cartes, PDF, statistiques, IA. Pour chacun, le fichier où il est branché.
- Pour l'IA : quels modèles, appelés depuis le navigateur ou depuis un serveur, où sont écrits les prompts, combien d'appels par action utilisateur, quel plafond de dépense.

### A4. Architecture

- Un schéma en texte des briques (navigateur, serveur ou fonctions, base de données, services tiers) et des flux entre elles.
- Où tourne la logique métier : dans le navigateur, dans des fonctions serveur, dans la base (déclencheurs, procédures stockées), ou un mélange.
- La liste des routes ou fonctions d'API, dans un tableau : méthode, chemin, rôle, authentification exigée ou non.
- Les tâches automatiques : tâches planifiées, files d'attente, webhooks entrants et sortants.
- Le découpage du code : logique métier dans les composants d'interface, composants géants, code dupliqué entre pages.
- Les environnements (développement, test, production) et ce qui les distingue dans la configuration.
- Les variables d'environnement : la liste des noms, jamais les valeurs, où elles sont utilisées, et la présence d'un `.env.example`.

### A5. Données

- Le type de base : SQL (PostgreSQL, MySQL, SQLite), NoSQL (Firestore, MongoDB, DynamoDB), ou autre (Google Sheets, Airtable, stockage du navigateur).
- L'hébergeur de la base (Supabase, Neon, Firebase…).
- Le schéma, dans un tableau : tables ou collections, champs principaux, relations. S'il n'est pas dans le dépôt, reconstitue-le à partir du code qui lit et écrit les données, et dis-le.
- Les migrations : versionnées dans le dépôt, ou faites à la main dans une console.
- Les garde-fous : clés étrangères, unicité, index, champs obligatoires, types.
- Les données personnelles : quelles tables et quels champs en contiennent. Signale les catégories sensibles (enfants, santé, données bancaires, pièces d'identité).
- Le contrôle d'accès aux données. Sur Supabase, la sécurité au niveau des lignes (RLS) est-elle activée table par table, et avec quelles règles ? La clé publique utilisée dans le navigateur permet-elle de lire ou d'écrire des tables non protégées ?
- Les fichiers stockés (photos, documents) : où, et en accès public ou privé.
- Les sauvegardes et les exports, tels que le code ou la configuration les montrent.
- Les données en double avec un autre logiciel, les imports et les exports existants.

### A6. Infrastructure et déploiement

- Où sont hébergés le front, le back, la base et les fichiers, et dans quelle région (Union européenne ou non).
- Comment on met en production : automatiquement depuis la plateforme de génération, par une intégration continue (GitHub Actions…), ou à la main.
- Les domaines et sous-domaines visibles dans la configuration.
- La surveillance : journaux, suivi d'erreurs (Sentry…), alertes. Ce qui se passe quand une erreur survient en production.
- Les limites des offres gratuites qui risquent d'être atteintes (nombre d'utilisateurs, requêtes, stockage).
- Le coût de fonctionnement estimé par service, à compléter avec la partie B.

### A7. Comptes et accès

Dresse l'inventaire des comptes nécessaires pour reprendre l'outil, dans un tableau : service, rôle, ce que le code en utilise, accès nécessaire pour le reprendre. Les colonnes « au nom de qui » et « coût mensuel » se remplissent avec les réponses de la partie B. Écris « à confirmer » quand ni le code ni les réponses ne permettent de savoir.

### A8. Sécurité

Pour chaque point, donne ce que tu as trouvé, la preuve (fichier et ligne) et une priorité. **P0** : bloquant, à corriger avant toute mise en production. **P1** : à corriger avant d'arrêter l'ancien logiciel. **P2** : amélioration après la bascule.

- **Secrets dans le dépôt.** Clés, mots de passe ou jetons présents dans le code actuel ou dans l'historique Git. Donne le nombre et l'emplacement, jamais la valeur.
- **Secrets exposés au navigateur.** Variables publiques (`VITE_`, `NEXT_PUBLIC_`, `REACT_APP_`) qui contiennent une clé secrète, clé `service_role` de Supabase, clé d'IA appelée depuis le navigateur.
- **Authentification.** Méthode, règles des mots de passe, double authentification, durée des sessions, réinitialisation du mot de passe, vérification de l'e-mail.
- **Autorisations.** Les droits sont-ils vérifiés côté serveur, ou seulement masqués dans l'interface ? Un utilisateur peut-il lire ou modifier les données d'un autre en changeant un identifiant dans une adresse ou une requête ? Raisonne sur le code, ne teste rien sur la production.
- **Administration.** Les pages et routes d'administration sont-elles protégées ?
- **Entrées utilisateur.** Validation côté serveur, requêtes SQL construites à la main, HTML injecté (`dangerouslySetInnerHTML`, `v-html`), envoi de fichiers (types, tailles).
- **Formulaires et API.** Limitation du nombre de requêtes, anti-robot, règles CORS, en-têtes de sécurité.
- **Webhooks.** Signature vérifiée pour les paiements, les e-mails et les autres services.
- **Journaux.** Contiennent-ils des données personnelles ou des secrets ?
- **IA.** Données personnelles envoyées au modèle, plafond de dépense, protection contre les instructions malveillantes glissées dans les contenus (injection de prompt).
- **RGPD.** Durée de conservation, suppression d'un compte et de ses données, export des données d'une personne, hébergement hors Union européenne.
- **Dépendances.** La synthèse des vulnérabilités relevées en A3.

Termine par une note de sécurité globale sur 5, justifiée en trois lignes.

### A9. Qualité du code

- **Échantillons.** Pour chaque grand module (pages, composants, API ou fonctions, accès aux données, scripts), cite un extrait représentatif de 20 à 40 lignes, avec son chemin, suivi de ton avis en trois lignes. Ajoute le fichier le mieux écrit et le moins bien écrit du dépôt. Aucun secret ni donnée personnelle dans les extraits.
- **Langue.** Les noms de variables, de fonctions et de fichiers sont-ils en anglais, en français, ou mélangés ? Donne des exemples.
- **Commentaires.** Part approximative des fichiers commentés, langue des commentaires, utilité. Expliquent-ils pourquoi le code fait ce qu'il fait, répètent-ils le code, ou sont-ils des restes de génération (« Ajoute ta logique ici ») ?
- **Lisibilité.** Taille des fonctions et des composants, nommage, cohérence du style, outils de formatage et de vérification (Prettier, ESLint) configurés et respectés.
- **Typage.** TypeScript ou non, mode strict, nombre d'usages de `any`.
- **Gestion des erreurs.** Erreurs attrapées, affichées à l'utilisateur, ou avalées en silence.
- **Tests.** Présents ou non, de quel type, combien, ce qu'ils couvrent. Ne les lance que s'ils ne touchent à aucune donnée réelle ni à aucun service en ligne.
- **Traces de génération.** Fichiers énormes, logique copiée d'une page à l'autre, données factices restées en place, valeurs en dur, `console.log` oubliés, composants jamais utilisés.
- **Dette visible.** Nombre de `TODO`, `FIXME` et `HACK`, et les plus importants.

Termine par une note sur 5 pour chaque axe, justifiée en une ligne : lisibilité, structure, robustesse, testabilité, documentation.

### A10. Fonctionnel

- Les fonctionnalités, dans un tableau : fonction, état (complète, partielle, maquette), fichiers principaux.
- Les règles métier écrites en dur dans le code (tarifs, capacités, horaires, seuils), et où elles se trouvent.
- Les cas limites non gérés que tu repères : champs vides, doublons, dates et fuseaux horaires, modifications simultanées.
- Les parcours incomplets : boutons sans action, pages vides, données factices, messages d'erreur absents.

### A11. Forces et faiblesses

Cinq forces et cinq faiblesses, chacune en une ligne, avec sa preuve.

### A12. Si c'était à refaire

- Ce que tu garderais tel quel.
- Ce que tu changerais si tu repartais de zéro (technologies, architecture, données, sécurité, organisation du code), et pourquoi.
- Pour chaque grand module : garder, reprendre ou réécrire, avec un effort estimé (petit, moyen, gros).

### A13. Ce qui bloque la mise en production

Les dix actions prioritaires, dans l'ordre, chacune avec sa priorité (P0, P1, P2) et son effort estimé.

## Partie B : les questions pour vous

Dix questions. Une estimation suffit, et « je ne sais pas » est une réponse utile.

**Les coûts**

1. Quel logiciel l'outil remplace-t-il, et combien coûte-t-il par mois ?
2. Combien coûtent par mois les services qui servent à construire et à faire tourner l'outil (Lovable, Claude, Codex, Cursor, hébergement, base de données…) ?

**Le temps passé**

3. Combien de temps a pris la construction de l'outil jusqu'ici ?
4. Combien de temps y passez-vous encore chaque semaine, pour le corriger ou le faire évoluer ?
5. Combien de temps l'outil fait-il gagner chaque semaine, et à qui ?

**Les objectifs**

6. Combien de personnes s'en servent aujourd'hui, et combien dans un an ?
7. Qu'attendez-vous de l'outil dans six mois ?
8. Pour quand voulez-vous arrêter l'ancien logiciel ?

**Deux vérifications**

9. L'outil contient-il des données personnelles (salariés, clients, familles, enfants) ?
10. Les comptes (code, hébergement, base de données) sont-ils au nom de l'entreprise ou d'une personne ?

## Partie C : commandes utiles

Des commandes en lecture seule, à adapter à la machine. Utilisées telles quelles, elles n'affichent aucune valeur secrète.

```bash
git log --oneline | wc -l                                  # nombre de commits
git log --reverse --format=%ad --date=short | head -1      # date du premier commit
git log -1 --format=%ad --date=short                       # date du dernier commit
git shortlog -sn --no-merges | wc -l                       # nombre d'auteurs
git branch -a                                              # branches
git ls-files | grep -iE "(^|/)\.env"                       # fichiers d'environnement suivis par Git
cloc . --exclude-dir=node_modules,dist,build,.next         # lignes par langage, si cloc est installé
grep -rnE "TODO|FIXME|HACK" --exclude-dir=node_modules . | wc -l
grep -rlE "sk_live_|sk_test_|service_role|ghp_|AKIA|BEGIN PRIVATE KEY" --exclude-dir=node_modules .   # fichiers qui contiennent un secret probable
git log --all -p | grep -cE "sk_live_|service_role|ghp_|AKIA"   # secrets probables dans l'historique, compte seulement
npm audit --omit=dev                                       # vulnérabilités, sans rien installer
```

## Partie D : format du rapport

Le rapport suit ce plan, dans cet ordre.

```markdown
# Rapport d'audit : <nom de l'outil>

## En-tête
- Date de l'audit
- Dépôts audités et commit de référence (identifiant court)
- Outil utilisé pour l'audit
- Ce qui n'a pas pu être lu ou vérifié

## Synthèse
- L'état de l'outil en trois phrases
- Les trois risques majeurs
- Le verdict : prêt pour la production, à sécuriser avant la production, ou à reconstruire en partie, avec une phrase de justification

## A1 à A13
Une section par question de la partie A, dans l'ordre,
chaque réponse marquée [Vérifié], [Déduit], [Déclaré] ou [Inconnu].

## Registre des risques
| N° | Côté (technique ou fonctionnel) | Constat | Preuve | Impact | Priorité (P0, P1, P2) | Effort (petit, moyen, gros) |

## Notes
| Axe | Note sur 5 | Justification |
Axes : sécurité, lisibilité, structure, robustesse, testabilité, documentation.

## Réponses de la partie B
Les réponses telles que données, question par question.

## Annexes
- Arborescence sur trois niveaux
- Extraits de code de A9
```