Le bon moment pour faire auditer une app construite avec l'IA ne se résume pas à un nombre d'utilisateurs. Une architecture simple peut servir plusieurs milliers de personnes. Une autre peut devenir difficile à maintenir bien avant le premier client payant.
Le signal important est le changement de rôle du produit. Au départ, l'app sert à tester une idée, un parcours et un marché. Ensuite, elle doit pouvoir être reprise, développée et exploitée avec des engagements plus précis. C'est à ce moment que l'ingénierie doit compléter la vitesse obtenue grâce au vibe coding.
Voici les six situations qui justifient le plus souvent un état des lieux.
1. Une autre personne doit reprendre le code
Le fondateur n'est plus le seul à travailler dans l'outil. Un développeur, une agence ou une équipe interne doit comprendre le projet, l'exécuter localement et estimer une modification.
Le nombre de lignes d'un fichier ne suffit pas à juger la qualité. Un fichier très long peut toutefois révéler plusieurs responsabilités mélangées. Le signal décisif apparaît lorsque la personne chargée de la reprise ne peut pas isoler une fonctionnalité, lancer les tests ou expliquer les dépendances sans reconstruire mentalement toute l'application.
2. Chaque évolution devient difficile à prévoir
Une petite modification prend plusieurs tentatives. Une correction réintroduit un ancien problème. L'outil modifie des parties qui semblaient sans rapport avec la demande.
Ce comportement ne signifie pas automatiquement qu'il faut reconstruire. Il indique que les frontières du code, les tests ou la gestion des dépendances ne jouent plus leur rôle. Un audit permet alors de distinguer quelques zones à isoler d'un problème plus structurel.
3. Un tiers demande des garanties
Un client veut connaître l'emplacement des données. Un investisseur demande qui possède le code. Un partenaire veut comprendre les sauvegardes ou la procédure en cas d'incident. Une équipe technique doit chiffrer la suite.
Ces questions ne se traitent pas avec une promesse générale. Elles demandent une carte des composants, des comptes, des accès et des responsabilités. Le Scan transforme cette carte en réponses compréhensibles et vérifiables.
4. L'app commence à porter des engagements
Paiements, données personnelles, contrat important, disponibilité attendue ou accès accordé à une organisation : le produit n'est plus seulement un test. Les conséquences d'une erreur changent, même si le nombre d'utilisateurs reste faible.
Le travail consiste à adapter les garanties au contexte : règles d'accès, sauvegardes, authentification, journaux, alertes et procédure de reprise. La checklist de lancement permet déjà d'identifier une partie de ces besoins.
5. La plateforme commence à décider à ta place
Une fonctionnalité dépend d'un service que tu ne peux pas remplacer. Les coûts deviennent difficiles à anticiper. Le domaine, les données ou les clés vivent sur un compte mal identifié. Une équipe ne sait pas reproduire le déploiement ailleurs.
La solution n'est pas forcément de quitter la plateforme. Lovable, Bolt, v0, Replit et Base44 peuvent rester de bons choix. L'audit sert à distinguer une dépendance acceptée d'une contrainte inconnue, puis à documenter un chemin de sortie si le projet en a besoin.
6. Tu ne peux plus chiffrer la prochaine étape
Tu sais ce que tu veux ajouter, mais personne ne peut dire si cela prendra deux jours ou six semaines. Chaque estimation contient une réserve importante parce que l'état du code, les données et les dépendances restent inconnus.
C'est souvent le signal le plus proche du problème économique réel. La dette technique ne coûte pas seulement le jour où l'app tombe. Elle coûte chaque fois qu'une décision devient plus lente, qu'un devis doit intégrer davantage d'incertitude ou qu'une équipe refuse la reprise faute de visibilité.
Ce qui ne constitue pas un verdict
Une app n'est pas condamnée parce qu'elle a été construite avec l'IA, parce qu'un fichier est long ou parce qu'elle approche un certain nombre d'utilisateurs. Aucun de ces éléments ne suffit à recommander une reconstruction.
La décision doit comparer des faits : coût des corrections, difficulté de reprise, risques confirmés, trajectoire du produit et coût d'une alternative. Dans la majorité des cas, une Intervention ciblée conserve l'acquis. La Reconstruction reste réservée aux limites structurelles dont la correction coûterait davantage que le remplacement.
Trois étapes, trois niveaux de discipline
Pendant l'exploration, la checklist des bases protège le code, les comptes et les données. Quand une version utilisable existe, quelques tests et une documentation minimale facilitent déjà la reprise. Lorsque plusieurs des six signaux apparaissent, le Scan donne une base de décision avant d'engager des développements supplémentaires.
Il ne s'agit donc pas de choisir entre vibe coding et développement classique. L'IA peut continuer à participer au projet. Il s'agit de reconnaître le moment où sa vitesse doit être encadrée par des choix d'ingénierie explicites.