Observe before changing
Un audit READ-ONLY précède toute modification sensible.
Méthode / De l’analyse à la production
Ma méthode d’AI-assisted engineering
Mon approche consiste à utiliser l’IA comme un accélérateur de conception, d’analyse et d’exécution, tout en conservant une responsabilité humaine forte sur les décisions, la sécurité, la qualité et la mise en production.
Au fil de mes expérimentations, j’ai progressivement structuré une méthode qui distingue clairement ce qui peut être confié à l’IA de ce qui doit rester sous contrôle humain.
01 / Le parcours
Du besoin à la production
Chaque étape prépare la suivante. Le niveau de contrôle dépend du risque ; le backup et la migration s’appliquent aux opérations et aux projets concernés.
Besoin
Comprendre le problème avant de parler de solution.
Cadrage
Définir le périmètre, les contraintes et le comportement attendu.
Audit READ-ONLY
Demander à l’IA d’observer avant de modifier.
Décision humaine
Valider l’approche avant implémentation.
Implémentation assistée par IA
Utiliser Codex et les outils IA pour produire les changements ciblés.
Tests automatisés
Vérifier les régressions et les règles techniques.
Recette réelle
Tester dans le vrai navigateur et l’environnement concerné.
PRECOMMIT
Relire le diff, vérifier le périmètre, les migrations et les risques.
Commit / Push
Créer un checkpoint versionné propre et partager les changements validés.
Build
Construire un artefact identifiable et reproductible.
Backup
Créer un point de restauration avant une opération sensible.
Migration
Appliquer les changements de schéma de manière contrôlée, lorsque le projet le nécessite.
Déploiement
Changer une seule variable à la fois lorsque possible.
Smoke test PROD
Valider immédiatement les fonctions critiques en production.
02 / Les responsabilités
Une assistance encadrée
Déléguer une tâche à l’IA ne transfère pas la responsabilité. Les propositions restent soumises à la compréhension, à la revue et à la validation humaines.
Ce que je délègue à l’IA
- Analyse d’un repository
- Exploration de solutions
- Génération de code
- Préparation de tests
- Revue de diff
- Diagnostic d’erreurs
- Documentation technique
- Préparation de scripts et commandes
Ce qui reste sous responsabilité humaine
- Définition du besoin
- Arbitrages fonctionnels
- Validation des risques
- Protection des données
- Décisions de sécurité
- Opérations destructives
- Validation navigateur réelle
- Choix de migration
- Décision de mise en production
- Décision de rollback
03 / Les garde-fous
Cinq principes de travail
Trust, but verify
Une réponse PASS n’est pas une preuve suffisante : les résultats doivent être examinés.
Keep changes reversible
Préparer les checkpoints Git, les backups et le rollback avant une opération risquée.
Separate evidence from assumption
Distinguer test automatisé, simulation et validation réelle.
Human accountability
La responsabilité finale reste humaine.
04 / Une évolution de la pratique
Du vibe coding à l’AI-assisted engineering
Le vibe coding est utile pour explorer rapidement une idée. Mais lorsqu’un produit doit être maintenu, sécurisé et exploité, la génération de code ne suffit plus.
Mon approche ajoute progressivement des tests, de la traçabilité, des contrôles, de la sécurité, des migrations, des possibilités de rollback et de la validation humaine.
Il s’agit d’adapter la pratique à la maturité du produit, à ses usages et aux risques associés.
05 / Les enseignements
Retours d’expérience
Trois situations issues de l’expérience KOUSSEVO, présentées de manière générique, sans données privées.
Tests PASS, comportement incorrect
Des tests automatisés passent alors que le comportement observé dans le navigateur est incorrect.
Leçon retenueToujours compléter les tests automatisés par une recette réelle.
Une migration préparée et contrôlée
Une migration de base de données additive est précédée d’un backup et d’un pré-check.
Leçon retenueL’IA peut préparer l’opération ; la décision et la validation du checkpoint restent humaines.
Session valide, activité réelle
Une session valide ne signifie pas que l’utilisateur est réellement actif.
Leçon retenueRéévaluer les modèles simples face aux cas réels et préciser ce que les indicateurs mesurent.
Pour poursuivre
La méthode à l’épreuve de la pratique
Explorer le projet et les enseignements consignés dans le Lab.