Reconstruction en 24 heures : un parcours, des vérifications d'acceptation claires

Quand un prototype est vraiment irrécupérable

Un prototype est irrécupérable lorsque le réparer prend plus de temps et comporte plus de risques que de reconstruire une petite version fiable. C’est courant avec les apps générées par l’IA : elles paraissent correctes dans une démo, puis se délient quand de vrais utilisateurs s’inscrivent, réinitialisent des mots de passe ou tentent de payer.

Quelques signes clairs apparaissent vite :

• Les bugs réapparaissent après de petits changements (code fragile).
• Des failles de sécurité que vous ne pouvez pas fermer avec confiance (secrets exposés, authentification faible, risque d'injection).
• Logique emmêlée que personne ne peut expliquer : on ne sait pas ce qu’un changement va casser.
• Fondations manquantes (pas de tests, modèle de données flou, état désordonné).
• Comportement « ça marche sur ma machine » qui bloque le déploiement.

Essayer de « tout réparer » fait normalement exploser les délais. Chaque correctif découvre une dépendance, une hypothèse codée en dur, une pièce collée sans plan. Le travail se transforme en débogage sans fin au lieu de construction.

Une reconstruction en 24 heures est une remise à zéro contrôlée. Elle ne consiste pas à recréer chaque écran, migrer chaque cas particulier ou polir l’UI. Cela signifie se mettre d’accord sur la version la plus petite qui peut fonctionner en production pour un parcours utilisateur clé, avec des vérifications qui prouvent que ça marche.

Définir l’objectif pour une reconstruction en 24 heures

Une reconstruction de 24 heures ne concerne pas votre produit de rêve. Elle concerne une tranche fonctionnelle que vous pouvez livrer et exploiter sans la surveiller en permanence.

Traitez l’objectif comme un contrat avec le temps. Chaque décision doit répondre à une question : cela nous garde-t-il dans le périmètre des 24 heures, ou cela transforme-t-il le travail en projet plus long ?

À quoi ressemble le succès

Le succès, c’est un seul parcours utilisateur stable, testable et déployable. « Déployable » compte autant que « marche sur mon laptop », car beaucoup de prototypes échouent dès que vous ajoutez un hébergement réel, de vrais secrets et de vrais utilisateurs.

Rédigez une courte déclaration de réussite qu’on peut lire à voix haute. Exemple : « Un nouvel utilisateur peut s’inscrire, se connecter, effectuer l’action principale et voir le résultat, avec gestion des erreurs et données sauvegardées correctement. »

Ajoutez ensuite des vérifications d’acceptation faciles à vérifier :

• Le parcours fonctionne de bout en bout dans un environnement propre avec des valeurs de config réelles.
• Les erreurs affichent un message clair (pas un écran blanc).
• Les données sont sauvegardées et se rechargent correctement après un rafraîchissement.
• Les bases de la sécurité sont en place (pas de secrets exposés, trous d’injection évidents traités).
• Le déploiement sur l’hôte choisi fonctionne sans bidouilles manuelles.

Ce que vous ne ferez pas encore

Pour protéger la limite temporelle, précisez ce qui est reporté. Les éléments « pas encore » courants incluent les systèmes de rôles complets, les cas de facturation, les tableaux d’administration, l’analytics, l’optimisation des performances et les grosses migrations.

Une règle simple : étiquetez chaque demande « requis pour le parcours unique » ou « futur ». Si c’est futur, mettez-le de côté.

Exemple concret : pour un prototype de réservation, l’objectif jour 1 pourrait être « rechercher la disponibilité et confirmer une réservation ». Les avis, coupons, parrainages et l’import des anciennes données de test peuvent attendre.

Choisir un seul parcours utilisateur à reconstruire en premier

Cette approche ne fonctionne que si vous choisissez un parcours utilisateur unique et traitez tout le reste comme ultérieur. Choisissez le parcours qui crée le plus de valeur rapidement (votre premier moment « aha ») ou qui élimine le plus grand risque (comme une authentification cassée ou des écritures de données non sécurisées).

Évitez les parcours qui semblent simples mais cachent des dépendances lourdes. « Voir le tableau de bord » dépend souvent des permissions, du modèle de données, des jobs en arrière-plan et des cas limites. Un meilleur premier parcours force l’essentiel à apparaître : connexion, écriture réelle en base et un écran de réussite clair.

Rédigez le parcours en 5 à 10 étapes simples. Gardez chaque étape comme une action ou une vue de l’utilisateur, pas une tâche interne.

Exemple (inscription jusqu’au premier élément enregistré) :

Étape 1 : L’utilisateur ouvre l’app. Étape 2 : L’utilisateur clique sur « Créer un compte ». Étape 3 : L’utilisateur saisit email et mot de passe. Étape 4 : L’app valide et crée le compte. Étape 5 : L’utilisateur arrive sur l’écran principal. Étape 6 : L’utilisateur crée un élément (note, tâche, lead, etc.). Étape 7 : L’app sauvegarde et l’affiche dans une liste.

Rédiger des vérifications d’acceptation qui alignent tout le monde

Une journée de reconstruction échoue quand le « terminé » est vague. Transformez votre parcours choisi en contrôles clairs pass/fail. Si un contrôle peut être débattu, réécrivez-le.

Rédigez des contrôles comme si vous testiez en tant qu’utilisateur de première heure un jour où vous êtes fatigué, faisant des erreurs réelles. Gardez-les petits et spécifiques. Lie z-les à un comportement visible (ce que l’utilisateur voit) plus une ou deux vérifications backend (ce qui doit être vrai côté serveur).

Exemples de contrôles pour « se connecter et atteindre le tableau de bord » :

• Connexion réussie : Avec un email et mot de passe valides, l’utilisateur atteint le tableau de bord et voit son nom en moins de 3 secondes.
• Mauvais mot de passe : Avec un email valide et un mauvais mot de passe, l’app affiche une erreur claire et ne connecte pas l’utilisateur.
• Formulaire vide : Si l’email ou le mot de passe est vide, l’app bloque l’envoi et indique ce qui manque.
• Fiabilité : Après connexion, un rafraîchissement garde l’utilisateur connecté (ou le déconnecte clairement). Sur un réseau lent, l’app affiche un état de chargement et n’envoie pas deux fois la requête.
• Bases de la sécurité : Le tableau de bord exige une authentification (pas d’accès direct), les entrées sont validées et les secrets ne sont pas exposés côté client.

Ajoutez un ou deux cas limites correspondant à votre produit (lien magique expiré, compte verrouillé, utilisateur supprimé). N’ajoutez pas toutes les fonctions futures.

Cadrer la reconstruction sur la plus petite tranche expédiable

Pensez au périmètre comme à faire sa valise pour une nuit : prenez ce dont vous avez besoin pour demain, pas tout ce que vous possédez.

Ciblez uniquement ce que le parcours choisi touche. Écrivez-le comme trois inventaires : écrans, endpoints API et données. Tout ce qui n’est pas sur ces listes est hors périmètre, même si ça a l’air rapide.

Une définition simple de tranche :

• Écrans nécessaires pour compléter le parcours
• Endpoints API dont ces écrans ont besoin (auth, lecture, écriture)
• Modèles de données et champs requis pour ce flux

Les dépendances externes sont souvent là où les reconstructions dérapent. Si une dépendance est lente à configurer ou difficile à tester, simulez-la pendant les premières 24 heures et laissez une jonction claire pour la remplacer par la vraie chose. Exemple : stockez un statut « paiement en attente/succès » et utilisez une réponse de succès factice, plutôt que d’essayer d’achever toute la configuration de facturation sous pression.

Fixez des limites par écrit pour que personne ne « corrige juste une chose de plus » :

• Pas de redesign ou de polish UI au-delà de la convivialité de base
• Pas de migrations sauf si le parcours ne peut pas fonctionner sans
• Pas de parité fonctionnelle avec l’ancien prototype
• Pas de refactors en dehors de la tranche reconstruite
• Pas de nouvelles intégrations sauf si nécessaire pour compléter le parcours

Un plan pratique sur 24 heures (étape par étape)

Traitez la journée comme une livraison chronométrée, pas une mission de sauvetage. L’objectif est un parcours fonctionnel en conditions production, avec des vérifications d’acceptation claires et une courte liste de contraintes (stack, hébergement, données à conserver, et ce que vous ne ferez pas aujourd’hui).

Un plan simple :

• Heure 0 à 2 : Verrouiller le parcours unique, écrire les vérifications d’acceptation, confirmer les contraintes (comptes, rôles, paiements, email, ou rien), et geler la liste de fonctionnalités. Capturez les risques connus comme les clés API manquantes.
• Heure 2 à 8 : Construire le flux central de bout en bout avec l’UI la plus petite qui prouve que ça marche. Gardez la mise en page simple.
• Heure 8 à 16 : Ajouter les parties ennuyeuses mais critiques : règles d’auth, validation des entrées, contrôles de permissions, écritures sûres en base et messages d’erreur utiles.
• Heure 16 à 22 : Exécuter les vérifications d’acceptation comme un script de test. Corriger les échecs, retirer le code mort, s’assurer que le comportement est reproductible deux fois de suite.
• Heure 22 à 24 : Préparer le déploiement et rédiger une courte note de passation : ce qui a été construit, comment l’exécuter, lacunes connues, étapes suivantes.

Exemple : si le parcours est « inscription, création d’un espace de travail, invitation d’un coéquipier », livrez-le avec des écrans basiques, des règles de permission réelles et des messages d’erreur propres. N’ajoutez pas les photos de profil, l’analytics ou un tableau d’administration complet.

Reporter en toute sécurité les fonctionnalités non critiques et les migrations

Les « jolis à avoir » sont ce qui transforme une reconstruction d’un jour en une semaine.

Commencez par reporter tout ce qui modifie beaucoup de fichiers sans aider à livrer le parcours unique. Les refactors globaux et les nettoyages « tant qu’on y est » sont des pièges temporels courants. Un écran propre et ennuyeux qui fonctionne vaut mieux qu’un écran soigné qui bloque la mise en production.

Les migrations sont l’autre tueur de reconstruction. Si possible, conservez le modèle de données actuel le jour 1, même s’il n’est pas parfait. Si l’ancien modèle est désordonné, placez une fine couche d’adaptation devant pour que votre nouveau code parle à une interface petite et stable.

Comment retarder les migrations sans créer un bazar

Quelques schémas sûrs :

• Conserver les tables existantes et ajouter une fonction de traduction ou une vue dans le code.
• Écrire les nouvelles données dans l’ancien schéma pour l’instant, en suivant les champs futurs dans une structure metadata.
• Si vous devez changer un champ, faites un changement additif (nouvelle colonne) plutôt que de tout remodeler.
• Ajouter la validation à la frontière (ce que vous lisez et écrivez), pas sur toute l’application.

Quand quelqu’un dit « on a besoin d’analytics, de rôles, de paiements », traitez-les comme des options à ajouter sauf si elles sont requises pour que le parcours unique se termine. Pour le jour 1, une table simple d’événements peut remplacer l’analytics complet. Un rôle admin unique peut remplacer un système de rôles complet. Une étape de facture manuelle peut remplacer la facturation automatisée si facturer n’est pas central pour l’instant.

Gardez une petite « liste de parking » avec un propriétaire et un déclencheur pour quand cela devient « maintenant ».

Pièges courants qui font déraper une reconstruction de 24 heures

La plupart des délais manqués proviennent d’une expansion de périmètre prévisible.

Un piège est de reconstruire deux parcours en même temps. Cela semble efficace de faire l’onboarding et la facturation ensemble, mais cela double les décisions, écrans et cas limites. Choisissez un parcours et rendez-le solide.

Un autre piège est des vérifications d’acceptation floues. Si l’équipe ne peut pas répondre « est-ce que ça passe, oui ou non ? », vous débattrez des détails tard dans la journée.

Quelques responsables récurrents :

• Commencer un second parcours « juste un peu » une fois le premier à moitié fait
• Des contrôles comme « ça marche » ou « assez rapide » sans test pass/fail
• Sous-estimer l’authentification et les permissions
• Mélanger des migrations dans la journée de reconstruction
• Construire uniquement le happy path et sauter les états d’erreur

L’auth mérite un avertissement particulier. « Connexion simple » cache souvent des heures de travail : expiration de session, réinitialisation de mot de passe, contrôles de permission sur chaque endpoint, limites de taux. Si vous ne la scellez pas, elle vous scellera.

Checklist rapide avant de déclarer le travail terminé

Avant d’arrêter le chrono, prouvez que la reconstruction fonctionne pour de vrais utilisateurs, pas seulement dans votre setup dev.

Utilisez ceci comme porte de sortie de release :

• Le parcours choisi se complète de bout en bout sans toucher la base de données à la main. Créez un nouveau compte (ou utilisateur de test), effectuez l’action centrale et confirmez que le résultat est sauvegardé et visible après un rechargement.
• L’auth est au bon endroit : les pages protégées bloquent les anonymes, les pages publiques restent publiques, et aucun secret n’apparaît dans le code client ou les logs.
• Les entrées échouent en sécurité : les champs requis sont appliqués, les mauvaises valeurs affichent des messages clairs et vous n’obtenez pas d’écran blanc.
• La performance de base est stable : les clics répétés ne créent pas d’enregistrements en double et l’action principale ne timeoute pas aléatoirement.
• Le déploiement n’est pas un mystère : le build passe dans un environnement propre, les variables d’environnement requises sont listées (nom, but, format d’exemple), et vous avez une note de rollback simple.

Exemple : si votre parcours est « inscription → créer un projet → inviter un coéquipier », testez-le en fenêtre incognito, puis répétez avec un second utilisateur. Si cela dépend d’étapes d’installation cachées, ce n’est pas fini.

Exemple : cadrer une reconstruction pour une app AI générée cassée

Un cas irrécupérable courant ressemble à ceci : une app construite par l’IA où la connexion marche parfois, casse après un rafraîchissement, et les données sauvegardées apparaissent aléatoirement (ou pas du tout). Vous pouvez passer des jours à courir après des fantômes. Une reconstruction d’un jour est souvent plus rapide si vous choisissez un chemin propre et le rendez ennuyeux et fiable.

Dans cet exemple, le seul parcours que vous reconstruirez : inscription, connexion, créer un élément et le revoir plus tard.

Vérifications d’acceptation vérifiables en quelques minutes :

• Un nouvel utilisateur peut s’inscrire et est automatiquement connecté.
• Un utilisateur connecté peut se déconnecter et se reconnecter avec succès.
• L’auth tient après un rafraîchissement (session conservée ou clairement expirée).
• La création d’un élément réussit et affiche un état de succès.
• L’élément apparaît immédiatement dans la liste de l’utilisateur.

Ajoutez des contrôles qui attrapent les échecs « ça marche sur ma machine » :

• L’élément est toujours là après avoir fermé le navigateur et être revenu plus tard.
• Chaque utilisateur ne voit que ses propres éléments.
• Aucun secret n’est exposé dans le navigateur ou les logs.
• Les erreurs affichent un message clair et n’effacent pas le travail de l’utilisateur.
• Le flux fonctionne dans un navigateur normal et dans une fenêtre privée.

Reportez : rôles admin, refonte complète, migration de fournisseur et intégrations tierces (paiements, email, analytics). Placez-les dans le parking avec des notes.

« Fait en 24 heures » signifie que le flux central est stable, déployé et testable par une personne non technique, avec une liste claire de ce que vous avez intentionnellement laissé de côté.

Étapes suivantes après les premières 24 heures

Si la journée se termine avec un parcours qui fonctionne de bout en bout, traitez cela comme un jalon. La façon la plus rapide de perdre l’élan est d’ajouter des extras « petits » sans écrire ce qui est fait, ce qui manque et ce qui est reporté.

Gardez tout sur une page :

• Vérifications d’acceptation (faites) : ce qui a passé, sur quel environnement, et limites connues
• Parking lot (plus tard) : fonctionnalités, intégrations, migrations, jolis à avoir
• Risques ouverts : failles de sécurité, cas limites de données, préoccupations de performance
• Propriétaire + date : qui décide de la suite et quand vous revoirz
• Choix jour 2 : le focus unique pour le prochain bloc de travail

Le jour 2 peut être un second parcours, une passe sécurité (surtout si vous avez touché à l’auth, aux paiements ou aux données utilisateurs), ou l’ajout de monitoring pour voir rapidement les échecs réels. Lancez les migrations seulement si vous devez vraiment déplacer des données maintenant.

Si vous avez hérité d’une base de code générée par l’IA avec des outils comme Lovable, Bolt, v0, Cursor ou Replit, un court diagnostic avant d’élargir le périmètre économise souvent des heures de tâtonnements.

Si vous voulez un deuxième jeu d’yeux sur un prototype AI cassé, FixMyMess (fixmymess.ai) se concentre sur le diagnostic et la réparation des bases de code générées par l’IA, y compris le durcissement de la sécurité et le refactor pour la production. Ils proposent un audit de code gratuit pour cartographier les problèmes et de nombreuses corrections sont réalisées en 48–72 heures.