Points de contrôle humains dans le développement d'IA : revues de 5 minutes pour la sanity du schéma, les règles d'auth, les actions destructrices et les paramètres de déploiement avant qu'ils ne deviennent problématiques.
La construction assistée par l'IA peut sembler instantanée. Vous décrivez une fonctionnalité, vous obtenez un écran fonctionnel, et l'app a l'air terminée. Le souci, c'est que de petits détails échouent souvent dans les cas limites : données réelles, permissions réelles, paramètres de production réels. Ces « petites » erreurs deviennent exactement ce qui se transforme en une semaine de nettoyage.
Un checkpoint est une courte pause humaine avant d'accepter ou de livrer un changement. Ce n'est pas une réunion et ce n'est pas un long cycle de QA. C'est un scan délibéré de 5 minutes où vous vous demandez : si c'est faux, qu'est-ce qui casse le plus ?
La plupart des nettoyages douloureux proviennent de quatre zones à haut risque :
Une pause rapide aide parce que ces problèmes sont transversaux. Une petite erreur de schéma se répercute dans les APIs, les écrans, les rapports et les migrations. Une erreur de permission peut devenir un incident de sécurité. Un mauvais paramètre de déploiement peut causer une indisponibilité.
Que vous codiez à la main ou que vous utilisiez un outil vibe-coding comme Koder.ai, la règle est la même : avancez vite, mais ajoutez de petits garde-fous là où le dommage est important.
Les checkpoints fonctionnent mieux quand ils sont prévisibles. Ne révisez pas tout. Révisez les quelques éléments qui coûtent cher à annuler.
Choisissez des moments qui déclenchent toujours un checkpoint : après avoir fini une fonctionnalité, juste avant le déploiement, et juste après une refactorisation qui touche aux données, à l'auth, à la facturation ou à tout ce qui est en production.
Réglez un minuteur sur 5 minutes. Quand il sonne, arrêtez-vous. Si vous avez trouvé un vrai risque, planifiez un suivi plus long. Si non, livrez avec plus de confiance.
Attribuez un rôle de réviseur, même si c'est « le vous du futur ». Faites comme si vous approuviez cela pour un collègue que vous ne pouvez pas interrompre plus tard.
Un petit template vous aide à rester cohérent :
Change:
Risky areas touched:
1 quick test to run:
Decision (proceed / adjust prompt / rollback):
Si vous construisez dans Koder.ai, facilitez volontairement la dernière étape. Les snapshots et le rollback transforment « je ne suis pas sûr » en une décision sûre.
La façon la plus rapide de perdre des jours est d'accepter un schéma de base de données qui ne correspond que « plus ou moins » à ce que vous vouliez. Les petites erreurs de données se répandent dans chaque écran, API, rapport et migration.
Commencez par vérifier si les entités principales correspondent au monde réel. Un CRM simple a généralement besoin de Customers, Contacts, Deals et Notes. Si vous voyez des noms vagues comme « ClientItem » ou « Record », vous êtes déjà en dérive.
Un scan de schéma de cinq minutes :
Un petit exemple : une table Invoices sans invoice_number unique semble correcte dans une démo. Un mois plus tard, des doublons apparaissent, des paiements sont appliqués au mauvais enregistrement, et vous écrivez des scripts de nettoyage et des mails d'excuse. Le détecter en revue, c'est un correctif de 30 secondes.
Si vous ne posez qu'une question, faites-la celle-ci : pouvez-vous expliquer le schéma à un nouveau coéquipier en deux minutes ? Si non, resserrez-le avant de construire dessus.
Les bugs d'auth coûtent cher parce que les démos du happy-path les cachent. Les deux échecs les plus courants sont « tout le monde peut tout faire » et « personne ne peut rien faire ».
Écrivez les rôles en mots simples : admin, staff, customer. Si l'app a des équipes, ajoutez workspace member et workspace owner. Si vous ne pouvez pas expliquer un rôle en une phrase, les règles vont s'étendre partout.
Appliquez ensuite une règle : accès minimal par défaut. Les nouveaux rôles doivent commencer sans accès ou en lecture seule et obtenir exactement ce dont ils ont besoin. Le code généré par l'IA est souvent permissif parce que ça fait passer les tests.
Pour vérifier rapidement, utilisez une petite matrice d'accès et testez réellement dans l'UI et l'API :
Les vérifications de propriété méritent une attention spéciale. « L'utilisateur peut lire Task » n'est pas suffisant. Ça devrait être « l'utilisateur peut lire Task où task.ownerId == user.id » (ou l'utilisateur appartient à l'espace de travail).
Les cas limites sont où les fuites surviennent : utilisateurs invités mais non acceptés, comptes supprimés, membres retirés avec d'anciennes sessions. Une seule omission peut se transformer en une semaine de nettoyage.
Si vous utilisez Koder.ai, demandez à l'assistant d'afficher les rôles et une table d'accès avant d'accepter les changements, puis vérifiez avec deux comptes test par rôle.
Les actions destructrices sont le chemin le plus rapide d'une petite erreur vers des jours de nettoyage.
D'abord, listez tout ce qui peut effacer ou écraser des données. Ce ne sont pas seulement les boutons supprimer. Ce sont reset, sync, import/replace, rebuild index, seed actions et outils admin larges.
Cherchez quelques signaux de sécurité clairs :
Pour la plupart des données générées par les utilisateurs, préférez le soft delete. Un simple champ deleted_at plus filtrage permet d'annuler et vous donne du temps si un bug apparaît plus tard.
Considérez aussi les changements de schéma comme potentiellement destructeurs. Supprimer des colonnes, changer des types et resserrer des contraintes peut perdre des données même si personne n'appelle un endpoint delete. Si l'IA a proposé une migration, demandez : que deviennent les lignes existantes et comment les restaurer ?
Si vous ne pouvez pas expliquer le plan de rollback en une phrase, ne déployez pas le changement destructeur.
La plupart des histoires de nettoyage commencent de la même façon : l'app fonctionnait en dev, puis la production se comporte différemment.
Séparez dev et production volontairement : bases de données, clés, buckets et fournisseurs différents. Si les deux environnements pointent vers la même base, un script de test peut polluer les données réelles, et un « quick reset » peut tout effacer.
Ensuite, regardez les secrets. Si vous voyez des clés dans un fichier de config, un prompt ou un message de commit, supposez qu'elles fuiront. Les secrets doivent être injectés au déploiement (env vars ou gestionnaire de secrets). La production doit refuser de démarrer si un secret requis manque. Ce refus coûte moins cher qu'un fallback silencieux.
Puis confirmez les paramètres exposés au navigateur : origins autorisés (CORS), URLs de redirection, callbacks OAuth. Ils sont faciles à presque faire correspondre, et c'est comme ça qu'on se retrouve à déboguer un « login cassé » alors que le code est correct.
Un contrôle de déploiement de cinq minutes :
Si vous déployez depuis Koder.ai, c'est aussi le bon moment pour confirmer que vous avez déployé le bon environnement et que le rollback est disponible si quelque chose semble incorrect.
Avant d'accepter un changement généré par l'IA et de le livrer, pausez-vous une minute. Vous ne révisez pas le style. Vous chassez les erreurs qui deviennent des nettoyages longs.
Un exemple : vous mergez une fonctionnalité « admin delete user ». En 60 secondes, vous voyez qu'il n'y a pas de vérification de rôle côté backend, seulement un bouton caché en UI. Un utilisateur peut appeler l'endpoint directement. Cette seule détection vous évite un incident.
Finissez par une question qui force la réalité :
Quelle est la pire chose qu'un utilisateur réel peut faire ici, volontairement ou par accident ?
Si la réponse inclut « supprimer les données des autres », « voir des enregistrements privés » ou « casser la production », stoppez et renforcez le changement.
Vous construisez un petit CRM et vous demandez à un outil IA d'ajouter un bouton « Delete customer » sur la page client. En quelques minutes, il génère l'UI, un endpoint backend et un changement de base pour supprimer les enregistrements liés.
Tout semble fonctionner : le bouton apparaît, la requête renvoie 200 et le client disparaît de la liste. Beaucoup d'équipes passent à autre chose.
Une revue de 5 minutes attrape deux problèmes :
Une revue rapide en pratique :
Un ajustement de prompt corrige le tout avant livraison :
“Make delete customer a soft delete. Keep invoices and logs. Only admins can delete. Add a confirmation step that requires typing DELETE. Return a clear error message when unauthorized.”
Pour éviter que ça casse à nouveau, documentez trois choses dans les notes du projet : la règle de suppression (soft vs hard), l'exigence de permission (qui peut supprimer), et les effets secondaires attendus (quelles données liées restent).
La sortie IA peut paraître confiante tout en cachant des hypothèses. L'objectif est de rendre ces hypothèses visibles.
Des mots qui devraient déclencher des questions de suivi : “assume”, “default”, “simple”, “should”, “usually”. Ils signifient souvent « j'ai choisi quelque chose sans confirmer qu'il convient à votre app ».
Modèles de prompt utiles :
“Rewrite your proposal as acceptance criteria. Include: required fields, error states, and 5 edge cases. If you made assumptions, list them and ask me to confirm.”
Deux autres prompts qui exposent rapidement les risques :
Pour l'auth :
“Show roles and permissions for each API route and UI action. For every role: allowed actions, denied actions, and one example request that should fail.”
Décidez ce qui doit toujours être vérifié par un humain, et gardez-le court :
La plupart des grands nettoyages commencent par le même petit choix : faire confiance à la sortie parce que ça marche maintenant.
“Ça marche sur ma machine” est le piège classique. Une fonctionnalité peut passer les tests locaux et échouer avec de vraies tailles de données, de vraies permissions, ou un environnement légèrement différent. La correction devient une pile de patchs d'urgence.
La dérive du schéma est un autre aimant. Quand les tables évoluent sans noms clairs, contraintes et valeurs par défaut, on finit avec des migrations ponctuelles et des solutions de contournement étranges. Plus tard, quelqu'un demande « que signifie status ? » et personne ne peut répondre.
Ajouter l'auth en dernier est pénible parce que ça réécrit les hypothèses. Si vous construisez tout comme si chaque utilisateur pouvait tout faire, vous passerez des semaines à boucher des trous sur des endpoints et écrans aléatoires.
Les actions destructrices provoquent les pires désastres. “Delete project” ou “reset database” est facile à implémenter et facile à regretter sans soft delete, snapshots ou plan de rollback.
Quelques causes récurrentes de nettoyage sur plusieurs jours :
La façon la plus simple de pérenniser les checkpoints est de les rattacher à des moments que vous avez déjà : démarrage d'une fonctionnalité, merge, déploiement et vérification.
Un rythme léger :
Si vous travaillez dans Koder.ai, son mode planning peut servir de checkpoint « avant de construire » : notez des décisions comme “orders can be created by signed-in users, but only admins can change status” avant de générer des changements. Les snapshots et le rollback facilitent aussi le fait de traiter « je ne suis pas sûr » comme une raison de revenir en arrière en toute sécurité, puis de régénérer avec un prompt plus clair.
Cinq minutes ne feront pas tout. Elles détectent de façon fiable les erreurs coûteuses tant qu'elles restent peu coûteuses.
Utilisez un checkpoint juste après qu'une fonctionnalité soit générée, juste avant le déploiement, et immédiatement après tout changement touchant les données, l'auth, la facturation ou les paramètres de production. Ces moments ont le plus grand « rayon d'impact », donc une petite revue attrape tôt les erreurs coûteuses.
Soyez strict : lancez un minuteur de 5 minutes et suivez toujours les mêmes étapes. Nommez le changement en une phrase, vérifiez ce qu'il touche (données, rôles, environnements), scannez les quatre zones à risque, effectuez un test simple de réalité, puis décidez : procéder, ajuster le prompt ou revenir en arrière.
Parce que les erreurs se propagent. Une petite erreur de schéma peut toucher APIs, écrans, rapports et migrations ; la corriger plus tard signifie souvent réécrire plusieurs couches. Attraper le problème quand le changement est encore récent est généralement une modification rapide plutôt qu'un projet de nettoyage.
Vérifiez que les tables et champs correspondent à des concepts réels, que les noms sont cohérents, que les relations sont complètes et que les contraintes sont intentionnelles (not null, unique, clés étrangères). Contrôlez aussi les index pour les recherches courantes afin d'éviter des effondrements de performance quand les données grossissent.
Supposez que l'interface peut tromper et testez les règles côté serveur. Confirmez les rôles en langage clair, partez du principe du moindre privilège, et vérifiez les contrôles de propriété côté serveur en essayant d'accéder à l'enregistrement d'un autre utilisateur en changeant un ID. Vérifiez aussi les endpoints de liste/recherche/téléchargement, pas seulement les écrans principaux.
Recensez toutes les opérations pouvant effacer ou écraser des données : imports, resets, mises à jour en masse, outils admin, etc. Exigez une confirmation explicite, limitez la portée, logguez qui a déclenché l'opération et préférez l'archivage ou le soft delete pour pouvoir récupérer en cas d'erreur.
Par défaut, utilisez le soft delete pour la plupart des données métiers afin de pouvoir annuler les accidents et enquêter sans perdre l'historique. N'utilisez le hard delete que lorsque la suppression permanente est réellement nécessaire, et assurez-vous de pouvoir expliquer le plan de récupération en une phrase avant de le déployer.
Séparez volontairement dev et prod (bases, clés, buckets, providers). Injectez les secrets au moment du déploiement (env vars ou gestionnaire de secrets), ne les laissez pas en dur. Vérifiez CORS, URLs de redirection et callbacks OAuth pour qu'ils correspondent au domaine réel. Enfin, activez le logging et le reporting d'erreurs en production sans y mettre de données sensibles.
Considérez-les comme un filet de sécurité, pas un substitut à la réflexion. Créez un snapshot avant un changement risqué et revenez en arrière immédiatement si la revue découvre un vrai risque ou une incertitude. Puis régénérez en fournissant un prompt qui inclut les contraintes, vérifications de rôle ou confirmations manquantes.
C'est un scan d'une minute pour les pannes coûteuses : clarté et contraintes du schéma, auth en défaut-par-défaut (server-side), confirmations et récupération pour les actions destructrices, et séparation propre dev/prod avec secrets sécurisés. Terminez en demandant quel est la pire erreur qu'un utilisateur réel pourrait faire ici ; arrêtez-vous si la réponse inclut perte de données, fuite de données ou casse de la production.