Checklist d'accueil client pour du code IA hérité

Pourquoi les agences ont besoin d'un process d'entrée différent pour du code IA hérité

Beaucoup de projets générés par l'IA font bonne impression en démo. Le chemin heureux fonctionne, l'interface est soignée, et personne ne remarque les lacunes jusqu'à l'arrivée des vrais utilisateurs. Ensuite, l'application commence à échouer de façon apparemment aléatoire : boucles de connexion, paiements qui expirent, données qui finissent au mauvais endroit.

Ce décalage est prévisible. Beaucoup de prototypes générés par l'IA sont conçus pour paraître complets avant d'être sûrs ou fiables. Les outils d'IA peuvent assembler des écrans rapidement, mais ils sautent souvent le travail ennuyeux qui maintient le logiciel stable en production.

Les points de défaillance se répètent : l'authentification est à moitié finie ou bricolée, des secrets traînent dans le repo ou dans le mauvais environnement, le modèle de données change chaque semaine, et le déploiement dépend d'étapes manuelles que seule une personne connaît. Si vous faites l'accueil comme pour une construction normale (liste de fonctionnalités, préférences design, délais), vous manquez ces risques et héritez des surprises.

Un bon accueil pour du code IA hérité porte moins sur « que voulez-vous ajouter ? » que sur « qu'est-ce qui peut casser la semaine prochaine ? » Obtenez des réponses claires à :

• Où les vrais utilisateurs sont bloqués aujourd'hui (pas ce qui est sur la roadmap)
• Qui contrôle le repo, l'hébergement et les comptes tiers
• Quelles données sont stockées et ce qui doit être protégées
• Ce qui doit fonctionner pour que l'entreprise tourne (connexion, paiement, emails)
• Ce qui a déjà été « réparé » et par qui

Si vous visez une fenêtre de stabilisation courte (souvent 48–72 heures), la première mission est d'arrêter l'hémorragie : rendre l'app fiable, boucher les failles de sécurité évidentes, et obtenir un déploiement reproductible. Les améliorations viennent après que les bases tiennent.

Scénario fréquent : un fondateur dit « c'est à peu près fini » parce que l'inscription en démo fonctionne. Votre accueil doit confirmer ce qui se passe quand 50 utilisateurs s'inscrivent, quand des mots de passe sont réinitialisés et quand l'app est déployée depuis zéro.

Fixez l'objectif : stabiliser d'abord, améliorer ensuite

Quand vous héritez du code généré par l'IA, le moyen le plus rapide de perdre la confiance est de promettre des fonctionnalités avant que les bases fonctionnent. Fixez un premier objectif clair : la stabilisation. Cela donne à tout le monde une définition partagée de « terminé » pour les premières 48–72 heures et rend votre estimation défendable.

Définissez « stabilisé » en termes simples que le client peut tester. Pour la plupart des apps, cela signifie :

• La connexion et l'inscription fonctionnent de bout en bout (y compris la réinitialisation de mot de passe, si utilisée)
• Le flux utilisateur principal s'achève sans plantages ni erreurs confuses
• L'app se déploie de la même manière à chaque fois (sans étapes mystérieuses)
• Les données ne sont pas visiblement à risque (pas de clés exposées, pas d'accès admin ouvert)

Puis tracez une ligne nette entre stabilisation, reconstruction et nouvelles fonctionnalités.

• La stabilisation arrête l'hémorragie.
• Une reconstruction remplace des fondations fragiles.
• Les nouvelles fonctionnalités attendent que le produit soit fiable.

Mettez ce langage dans votre accueil pour que toute l'équipe (et le client) utilise les mêmes définitions.

Posez des garde-fous tôt : calendrier, limites budgétaires et qui prend la décision finale quand vous faites face à des compromis comme « réparer vite » vs « réécrire proprement ». Nommez un approbateur et un secours, et accordez-vous sur des délais de réponse pour ne pas être bloqué pendant la fenêtre de stabilisation.

Enfin, choisissez un seul endroit pour les décisions et les exigences. Ça peut être un bref document ou un tableau de tickets, mais il doit répondre à trois questions : ce que l'app est censée faire aujourd'hui, ce qui compte comme défaut, et ce qui est hors du périmètre jusqu'après la stabilisation.

Questions rapides de triage projet (10 minutes)

Un appel de triage rapide évite les surprises. Le but n'est pas de comprendre chaque détail, mais d'apprendre ce que vous héritez, ce qui est cassé maintenant, et si une fenêtre de stabilisation de 48–72 heures est réaliste.

Utilisez ces questions pour obtenir les bases rapidement :

• Qui l'a construit (personne ou prestataire), et quel outil d'IA a été utilisé (Lovable, Bolt, v0, Cursor, Replit, etc.) ? Qu'est-ce qui a changé depuis qu'il « fonctionnait » ?
• Où tourne-t-il aujourd'hui : seulement sur l'ordinateur de quelqu'un, sur un site de staging, en production, ou nulle part ? Qui y a accès ?
• Qui l'utilise maintenant (si quelqu'un), et quels sont les 1–2 workflows prioritaires qui doivent marcher (inscription, paiement, réservation, modifications admin) ?
• Qu'est-ce qui échoue actuellement, en termes simples ? Demandez un exemple récent qu'un utilisateur a rencontré (message d'erreur, page blanche, données erronées).
• Y a-t-il des délais liés à une démo commerciale, un pilote, une levée de fonds ou un examen de conformité ? Qu'arrive-t-il si ça glisse d'une semaine ?

Écoutez les contradictions. S'ils disent « ça marchait la semaine dernière » mais aussi « personne ne peut se connecter », vous avez déjà une priorité : l'authentification et l'accès.

Exemple : un client a besoin d'une démo vendredi, l'app ne tourne que localement, et le dernier dev l'a « réparée » en collant des secrets dans le frontend. Ce n'est pas un sprint de fonctionnalités : c'est une mission de stabilisation courte : obtenir une build déployable, sécuriser les secrets, et rendre le chemin de démo fiable.

Accès et propriété : obtenez le contrôle avant de toucher le code

Avant d'ouvrir un repo ou de promettre un calendrier, assurez-vous que le client peut réellement accorder le contrôle. Avec du code IA hérité, le désordre n'est souvent pas que dans le code. Ce sont les comptes, les tokens et des déploiements à moitié terminés que personne ne possède.

Commencez par une question directe : où le code se trouve-t-il aujourd'hui ? Si la réponse est « sur l'ordinateur de quelqu'un » ou « dans un outil comme Replit » sans propriétaire clair, considérez cela comme un vrai risque. Accès d'abord, travail ensuite.

Accès minimum dont vous avez besoin

Demandez ces éléments en amont pour travailler en sécurité et éviter les surprises :

• Emplacement du repo et un vrai administrateur (GitHub, GitLab ou un autre hébergeur)
• Accès de déploiement (qui peut pousser en production, si la prod existe)
• Liste des environnements (dev, staging, prod) et s'il y a des partages
• Méthode de stockage des secrets (fichiers env, variables de dashboard, secret manager) et qui peut les faire tourner
• Propriété du domaine et des emails (qui contrôle le DNS et les paramètres d'email transactionnel)

Si le client ne peut pas fournir au moins un admin et un endroit sûr pour stocker les secrets, marquez une pause. Toucher le code sans propriété conduit à des connexions cassées, des données perdues ou une interruption de production.

Attentes autour des secrets et des déploiements

Les prototypes générés par l'IA ont souvent des clés exposées ou des mots de passe codés en dur. Même si l'app « marche », supposez que les secrets doivent être renouvelés.

Confirmez qui peut changer :

• Mots de passe de base de données et clés d'API
• Paramètres du fournisseur d'auth (apps OAuth, secrets JWT)
• Variables d'hébergement et paramètres de build

Exemple : vous héritez d'un prototype Bolt qui se déploie depuis un compte personnel, avec le mot de passe de la base collé dans le code. La bonne démarche est de transférer le repo, déplacer le déploiement vers un espace de travail détenu par l'agence, et faire tourner les secrets avant tout travail fonctionnel.

Flux critiques pour l'entreprise à confirmer (et quoi demander)

Pour éviter les surprises, mettez-vous d'accord sur les quelques flux qui doivent marcher quoi qu'il arrive. Cela vous évite de réparer la mauvaise chose en premier.

Commencez par l'identité et les permissions. « La connexion marche » ne suffit pas. Demandez qui doit pouvoir faire quoi, et où cette règle est appliquée. Si les permissions sont uniquement cachées dans l'UI, un utilisateur peut parfois les contourner en devinant un ID ou en appelant directement un endpoint.

Les paiements et la facturation demandent aussi une histoire claire en cas d'échec. Beaucoup de prototypes ne gèrent que le chemin heureux. Confirmez ce qui doit se passer quand une carte échoue, qu'un abonnement est annulé ou qu'un remboursement est nécessaire, et qui déclenche ces actions.

Définissez la sensibilité des données dès le début. Si l'app manipule des données personnelles, des infos de santé, des détails financiers ou des données sur des mineurs, vos choix de sécurité et de journalisation changent dès le jour un.

Gardez les questions pratiques :

• Auth : quels rôles existent (utilisateur, admin, staff) et que peut faire chaque rôle ?
• Paiements : qu'est-ce qui compte comme « payé », et que change quand le paiement échoue ou est remboursé ?
• Données : quels champs sensibles existent et faut-il supprimer certaines données sur demande ?
• Intégrations : quoi se connecte à l'email, CRM, stockage de fichiers, APIs IA ou webhooks, et qu'est-ce qui casse si ça tombe ?
• Accès admin : y a-t-il un panneau admin « temporaire », un mot de passe partagé ou une backdoor encore utilisée ?

Exemple : un fondateur dit « seuls les admins peuvent exporter les données clients ». Dans du code hérité, cette règle est parfois juste un bouton, pas une vérification de permission.

Signaux de risque que vous pouvez repérer au premier appel

Certains problèmes apparaissent avant même que vous voyiez le repo. Un bon premier appel porte moins sur les détails et plus sur les signaux : ce code peut-il tourner ailleurs, l'accès est-il propre, et peut-on faire confiance à ce qu'on vous dit ?

Surveillez ces drapeaux rouges :

• Il ne tourne que sur l'ordinateur d'une seule personne, ou ils disent « on ne peut plus déployer ». Cela signifie souvent un setup d'env manquant, des étapes de build cassées ou des services non documentés.
• Les secrets sont gérés à la légère : clés API collées dans le chat, tokens dans un doc partagé, ou « utilisez ce mot de passe admin ». Supposons une exposition jusqu'à preuve du contraire.
• L'auth est incohérente : « la connexion marche parfois », les rôles ne fonctionnent pas, ou un utilisateur peut voir les données d'un autre.
• Les bugs semblent aléatoires et disparaissent au rafraîchissement. Cela peut indiquer un état instable, des problèmes de cache ou des attentes mismatched entre frontend et backend.
• Pas de tests, pas de logs, et personne ne sait ce qui a changé en dernier. Sans piste d'audit, chaque correction devient de l'essai-erreur.

Quand vous entendez un ou plusieurs de ces signaux, utilisez des questions de suivi calmes pour transformer une douleur vague en périmètre clair :

• « Où ça tourne aujourd'hui, et qui peut le redémarrer si ça casse ? »
• « Comment les secrets sont stockés, et qui y a accès maintenant ? »
• « Quelles actions utilisateur doivent marcher à chaque fois pour que l'entreprise fonctionne ? »
• « Quand ça a-t-il fonctionné pour la dernière fois, et que s'est-il passé juste avant que ça casse ? »

Exemple : l'app a été construite dans Replit, le déploiement a cassé la semaine dernière, et ils partagent une clé Stripe dans Slack. C'est suffisant pour mettre en pause les demandes de fonctionnalités et basculer vers un accueil centré sur la stabilisation : contrôle, sécurité et déploiement reproductible.

Ce qu'il faut vérifier une fois dans le repo (haut niveau, non technique)

Une fois que vous avez accès, vous n'avez pas besoin de lire chaque fichier pour savoir si le projet est sûr à stabiliser. Un scan rapide vous dira si c'est un petit sauvetage ou une reconstruction plus profonde.

Commencez par la couche données, car les surprises là se répercutent partout. Cherchez des concepts dupliqués (par exemple users et app_users), des champs « source de vérité » flous, et des fichiers de migration manquants. Si le repo ne peut pas expliquer comment la base de données évolue dans le temps, les releases deviennent rapidement risquées.

Faites ensuite un balayage de sécurité basique, même si vous n'êtes pas expert en sécurité. Vérifiez si les entrées utilisateur sont traitées soigneusement, si les uploads sont restreints, et si quelque chose semble accepter du SQL brut ou des commandes non fiables. Scannez les secrets dans le repo (clés API, mots de passe). Si vous en trouvez, supposez qu'ils ont fuité.

Regardez aussi la structure. Les prototypes créés par l'IA copient souvent la même logique à plusieurs endroits. Cela rend les corrections lentes et facilite la réintroduction de bugs.

Une courte série de vérifications qui révèle généralement les plus gros risques :

• Y a-t-il une séparation claire backend vs frontend, ou tout est mélangé ?
• Voit-on la même logique répétée dans plusieurs fichiers ?
• L'auth et les permissions sont-elles gérées en un seul endroit ou dispersées ?
• Y a-t-il du reporting d'erreurs, ou ça échoue silencieusement ?
• Y a-t-il des éléments basiques comme des sauvegardes, des configs d'environnement et un chemin de déploiement simple ?

Enfin, repérez tôt les pièges de performance. Si les pages dépendent de nombreux appels API répétés, ou si l'app récupère sans cesse les mêmes données, vous verrez des temps de chargement lents et des timeouts lorsque de vrais utilisateurs arrivent.

Un plan simple de stabilisation 48–72 heures (pas à pas)

Une fenêtre de stabilisation n'est pas un sprint de fonctionnalités. Le but est de faire tourner l'app de façon fiable, arrêter l'hémorragie, et donner à tous une vue claire de ce qu'il faudra pour l'améliorer ensuite.

Le plan en 5 étapes

1. Get access, run it, and reproduce the worst failures. Collect repo access, hosting credentials, and environment variables. Then run the app the same way users do. Pick the top 3 failures and reproduce them with clear notes.

2. Freeze scope and define "done" for stabilization. Agree that new features wait. "Done" should be specific: sign in works, the main workflow completes, and deployment doesn’t rely on manual hacks.

3. Fix the blockers first. Prioritize anything that stops users or creates immediate danger: broken auth, exposed secrets, crashing pages, failing builds, and deployments that only work on one machine.

4. Add basic safeguards so it stays stable. Add simple logging, clear error messages, and a few smoke checks that catch the same break again.

5. Hand back a short report and the next decision. Summarize what was fixed, what’s still risky, and what you recommend next (refactor, security hardening, or rebuild).

Erreurs d'accueil fréquentes qui provoquent des déboires plus tard

La manière la plus rapide pour qu'un projet IA hérité déraille est de le traiter comme une construction normale. Un client peut demander des nouvelles fonctionnalités dès le premier jour, mais si la fondation est instable, chaque « petit changement » peut briser trois autres choses.

Erreurs courantes :

• Promettre des dates de livraison avant d'avoir effectué une fenêtre de stabilisation
• Attendre des jours pour obtenir les accès (repo, hébergement, base) puis prendre des décisions à la hâte
• Définir le succès comme « pas de bugs » au lieu d'une petite liste de flux business
• Corriger des problèmes de surface sans faire tourner les secrets exposés
• Déployer des changements en production sans plan de rollback

Exemple : un client demande « une option de paiement de plus » dans un prototype. Vous l'ajoutez, les paiements fonctionnent, mais une clé d'API fuitée cause ensuite de la fraude et l'agence est tenue responsable. Un accueil solide inclut une remise à zéro de sécurité (rotation des clés, revue d'auth) et un plan de rollback avant les travaux de fonctionnalité.

Checklist à copier-coller pour l'accueil (vérifications rapides)

Utilisez ceci quand vous devez confirmer les bases rapidement et éviter des surprises plus tard. Conçu pour un appel de transfert de 10–15 minutes plus un court suivi.

[ ] Access confirmed: repo + hosting + database + domain/DNS (who has admin?)
[ ] Third-party accounts listed: auth/email/payments/storage/analytics (who owns each?)
[ ] Security baseline: where secrets live today, how they will be rotated, and what data is sensitive
[ ] User roles: who can do what (admin, staff, customer) and which role is highest risk
[ ] Top 3 broken flows written down with a "done" definition for each
[ ] Deploy plan: how releases happen today and who can press the button
[ ] Observability: logs exist, error tracking is on, and someone will watch it after release
[ ] Backups: database backup status + restore test (or date of last known good backup)
[ ] 48-72 hour stabilization: what’s included (fix critical breakages, stop data leaks) vs excluded (new features, redesign)
[ ] Sign-off: one decision-maker for tradeoffs, plus a fallback if they are unavailable

Une façon simple de poser les attentes : la stabilisation signifie que l'app cesse d'échouer aux endroits les plus importants et que les failles de sécurité évidentes sont bouchées. Cela ne veut pas dire que le code est joli, rapide ou prêt à monter en charge.

Exemple : si un client dit « le checkout est cassé », précisez cela à un flux testable (page produit jusqu'au succès de paiement) et un propriétaire pour le compte de paiement. Sans ça, vous pouvez réparer le code et rester bloqué par un accès manquant.

Scénario d'exemple : du prototype hérité à une release stable

Un client vient avec un prototype Bolt utilisé pour susciter de l'intérêt. L'app paraît correcte en démo, mais les vrais utilisateurs ne peuvent pas se connecter. Parfois le bouton de login tourne indéfiniment, d'autres fois il crée des comptes sans les sauvegarder.

Au premier appel, utilisez un accueil axé stabilisation. Gardez le ton neutre : vous ne jugez pas la construction, vous déterminez ce qu'il faut pour la rendre fiable.

En pratique, cela signifie souvent :

• Confirmer le ou les flux qui doivent marcher cette semaine.
• Obtenir l'accès pendant l'appel : repo, hébergement, base, domaine, services tiers.
• Confirmer où vivent les secrets et qui possède les comptes.
• Noter les signaux de risque comme plusieurs fournisseurs d'auth à moitié câblés, clés codées en dur, ou un modèle de données fragile.
• Fixer l'objectif 48–72 heures : stabiliser, ajouter des garde-fous basiques, et livrer une petite release sûre.

En 2–3 jours, les équipes peuvent souvent stabiliser la connexion en corrigeant la gestion de session, en nettoyant les variables d'environnement et en ajoutant un logging d'erreur basique pour rendre les échecs visibles. Les problèmes de sécurité évidents (secrets exposés) peuvent être patchés, et les pannes « aléatoires » diminuent souvent quand quelques éléments entortillés sont simplifiés.

Ce qui devient généralement une proposition de reconstruction : une architecture qui bloque les changements, une propriété floue des comptes tiers, ou un schéma de base de données qui ne supporte pas un usage réel. Encadrez le compromis franchement : « On peut patcher pour fonctionner maintenant, mais si vous voulez des changements plus rapides après, une reconstruction coûtera moins cher que des réparations répétées. »

Étapes suivantes : rendre l'accueil répétable et réduire les surprises

Considérez l'accueil comme un petit produit à part entière. Quand le process est le même à chaque fois, vous passez moins de temps à courir après des détails et plus de temps à réparer ce qui compte.

Envoyez votre checklist avant le kickoff. Demandez au client de la renvoyer avec les accès en place. Si l'accès est « en cours », le projet est déjà en retard. Une règle simple : aucun travail ne commence tant que vous ne pouvez pas voir le repo et un environnement en fonctionnement.

Un rythme pratique : planifier une courte fenêtre de stabilisation avant d'estimer de nouvelles fonctionnalités. Placez 48–72 heures au calendrier pour confirmer ce qui existe, ce qui est cassé et ce qui est risqué. Après cela, vous pouvez estimer les améliorations avec moins de surprises.

Rédigez les risques en langage clair et obtenez un accord sur les priorités. Ce n'est pas de la paperasse : c'est pour éviter la confusion quand un « petit fix » tourne en problème de sécurité ou reconstruction.

Si vous avez besoin d'aide extérieure pour du code hérité généré par l'IA, FixMyMess (fixmymess.ai) réalise un diagnostic et des réparations, y compris le renforcement de la sécurité, le refactoring et la préparation au déploiement. Ils proposent aussi un audit de code gratuit pour faire émerger les problèmes avant que vous ne vous engagiez dans un plan.