La plupart des audits de MVP produisent un document. Un audit utile produit des décisions : ce qui brûle, ce qui peut attendre, et ce que coûte la correction.
Un audit technique de MVP répond à une seule question : cette base de code peut-elle porter les douze prochains mois de l'entreprise, et sinon, que faut-il changer exactement ? Tout le reste — préférences d'outils, débats de style, choix de framework — est du bruit.
Voici la checklist que nous parcourons dans les 48 premières heures. Elle est délibérément ordonnée par coût de l'erreur : les points du haut peuvent tuer une entreprise, ceux du bas coûtent de la vélocité.
1. Intégrité de l'argent et des données (coût d'échec le plus élevé)
Si le produit déplace de l'argent ou détient des données réglementées, cela passe en premier. Les bugs ici ne sont pas des incidents — ce sont des passifs. Nous cherchons :
- Si les soldes sont dérivés d'un journal en append-only, ou stockés comme un nombre modifiable que le code peut écraser
- L'idempotence sur chaque chemin de paiement et de webhook — une requête réessayée peut-elle débiter ou créditer deux fois ?
- Utiliser des décimales exactes ou unités entières avec règles par devise.
- Les frontières transactionnelles : un échec partiel peut-il laisser l'argent en double ou nulle part
- La réconciliation : existe-t-il un processus qui détecterait un écart, ou l'apprendriez-vous d'un client ?
2. Sécurité et contrôle d'accès
- Autorisation vérifiée côté serveur à chaque requête, ou supposée parce que l'interface masque le bouton
- Secrets dans des variables d'environnement et un gestionnaire de secrets, pas dans l'historique du dépôt
- PII et données de carte : ce qui est stocké, où, et si cela devrait l'être
- Vulnérabilités de dépendances réellement atteignables, pas seulement un chiffre rouge dans un rapport
- Isolation multi-tenant : une requête forgée peut-elle lire les données d'un autre client ?
3. Architecture et limites de montée en charge
Nous ne cherchons pas l'élégance. Nous cherchons le mur précis que le système va rencontrer, et à quelle distance il se trouve.
- Les points uniques de défaillance — la base de données, la file d'attente, le service que tout le monde appelle
- Les requêtes correctes à 1 000 lignes et fatales à 1 000 000 (N+1, index manquants, scans non bornés)
- Si le système peut être déployé sans interruption, et si quelqu'un a déjà essayé
- Le couplage qui empêche de livrer une fonctionnalité sans toucher cinq modules
- Si l'architecture correspond à la taille de l'équipe — des microservices à quatre développeurs sont un problème de montée en charge, pas une solution
4. Livraison et exploitation
Les bases de code ne se dégradent pas seules ; le processus décide de la vitesse. Ce que nous mesurons :
| Signal | Sain | Signal d'alerte |
|---|---|---|
| Fréquence de déploiement | À la demande, plusieurs fois par semaine | Mensuelle, cérémonielle, redoutée |
| Délai pour un petit changement | Heures à un jour | Semaines |
| Rollback | Une commande, éprouvée | Théorique |
| Couverture de test là où ça compte | Chemins argent et auth couverts | Taux élevé, chemins critiques non testés |
| Observabilité | Vous détectez avant les clients | Les clients sont votre monitoring |
5. Dette technique : triée, pas listée
Toute base de code a de la dette. En dresser la liste ne sert à rien. Ce qui compte, c'est la classification en trois catégories :
- Bloquante — empêche la roadmap ou met en risque l'argent/les données. À corriger maintenant.
- Cumulative — ralentit chaque changement futur. À planifier délibérément.
- Cosmétique — heurte le goût, ne coûte rien. À laisser tranquille.
Le but d'un audit n'est pas de trouver tout ce qui ne va pas. C'est de trouver les quelques choses assez graves pour compter, et de dire précisément ce qu'elles coûtent.
Ce que vous devriez recevoir à la fin
- Une liste priorisée de constats avec sévérité et impact business — pas un catalogue
- Pour chaque constat : la correction, une estimation réaliste, et ce qui arrive si vous ne faites rien
- Une roadmap séquencée : ce trimestre, le prochain, plus tard
- Des preuves — la requête, l'endpoint, la ligne exacte — pour que votre équipe puisse vérifier plutôt que croire
Transformer la première revue en backlog vérifiable
Une revue limitée dans le temps décrit sa couverture, pas l'absence de défauts. Chaque constat doit pouvoir être vérifié.
- Relier parcours touché, preuve et conditions de reproduction.
- Séparer défauts observés, risques supposés et zones inaccessibles.
- Attribuer chaque correctif et son test de régression.
Questions fréquentes
Combien de temps dure un audit technique de MVP ?
Un audit ciblé d'une base de code typique en phase seed prend 3 à 10 jours ouvrés selon la taille et la part du système qui déplace de l'argent. Les 48 premières heures couvrent les zones à plus haut risque — flux monétaires, sécurité, limites de charge — ce qui suffit généralement à savoir s'il existe un problème sérieux.
Avez-vous besoin d'accéder à nos systèmes de production ?
Non. Un accès en lecture au dépôt, l'architecture telle qu'elle est déployée et une session avec un développeur suffisent pour l'évaluation. L'accès production n'est nécessaire que si l'on nous demande aussi d'intervenir sur des incidents en cours.
Quelle différence entre une revue de code et un audit technique ?
Une revue de code évalue un changement. Un audit évalue le système face au plan d'affaires : peut-il porter la roadmap, survivre à la montée en charge, passer une due diligence d'investisseur et ne pas perdre d'argent. Il couvre l'architecture, l'intégrité des données, la sécurité et le processus de livraison — pas seulement le code.
Un audit va-t-il nous dire de tout réécrire ?
Presque jamais, et méfiez-vous de quiconque répond par défaut « réécriture ». Les réécritures sont l'option la plus coûteuse et généralement la mauvaise. Dans la plupart des cas, un petit nombre de corrections ciblées élimine le risque réel.
Que faire si l'accès au code ou à l'infrastructure manque ?
Marquer les contrôles concernés comme non vérifiés et préciser la décision bloquée. Une présentation peut contextualiser, sans remplacer une preuve d'exécution.
Envie de l'appliquer à votre base de code ?
Nous livrons des constats priorisés avec estimations d'effort — pas un PDF de 50 pages. Deux semaines, périmètre fixe.
Pour aller plus loin
Réparer un MVP en panne (sans tout recommencer)
Presque tout fondateur face à un MVP cassé demande s'il faut le réécrire. Presque à chaque fois, la réponse est non — et la raison est arithmétique, pas sentimentale.
Dette technique en startup : à partir de quand est-ce trop ?
Toute startup a de la dette technique, et l'essentiel était le bon choix. La question n'est pas comment l'éliminer — c'est quelles parties facturent des intérêts que vous ne pouvez plus payer.