Ce que la vérification a trouvé
Trois cas où l'outil avait tort ou allait trop loin.
- Bizcard. L'outil a ajouté une fonction que personne n'avait demandée. Un humain a décidé de la garder.
- ATS First. Le test utilisateur a été sauté. Deux défauts ont été découverts après la livraison.
- Annuaire IAS. La base de données a été coupée après 90 jours, faute d'inventaire des dépendances.
Ce que je vérifie à chaque fois : ce qui a été produit, ce que l'outil déclare avoir produit, et l'écart entre les deux.
Mes points de contrôle
- Avant de produire. Comprendre d'abord : la recherche documentaire précède les maquettes, même quand l'outil permet de générer tout de suite.
- Le contrat donné à l'agent. Quand je le modifie, je change d'abord l'exemple concret, parce que l'agent suit l'exemple plus fidèlement que la définition.
- Après avoir produit. Je confronte la sortie au contrat d'entrée, ligne à ligne, et pas seulement sa conformité de forme.
- La durabilité. J'inventorie ce qui cesserait de fonctionner si un service tiers changeait ses conditions.
- Ce que la loi exige. Les modèles omettent souvent mentions légales, politique de confidentialité et gestion des rôles : je les vérifie à chaque projet.
Limite : je n'ai pas tenu de journal de décisions au fil de l'eau. Plusieurs choix ont été reconstitués après coup, donc ne sont plus datables avec précision.
Environnement de travail
Orchestration IA
- Claude Code
- Lovable
- Google AI Studio
- Stitch
- Manus
- Higgsfield
Recherche
- Gemini Notebook
- Perplexity
- Reddit
Conception
Code et déploiement
- Visual Studio
- Antigravity IDE
- GitHub
- Vercel
- Render
- Supabase
- Google Cloud
CMS et e-commerce
- WordPress
- Elementor
- WooCommerce
Organisation
Limite : ces constats viennent de quatre terrains de recherche menés pour un mémoire, sans client ni utilisateurs réels.
Ces terrains sont analysés dans mon mémoire de Master 2 sur l'IA générative dans les systèmes de conception numérique agile, soutenu en septembre 2026 à l'UPHF.
Voir les projets