Ma méthode de dev avec l’IA : vision produit, specs Markdown, co-coding et validation humaine
Bonsoir ! Je profite du week-end pour parler du sujet qui fâche 🔥
Je voulais partager ma méthode actuelle de développement, parce qu’elle est un peu hybride et qu’elle a pas mal changé avec l’arrivée des LLM.
Je travaille surtout sur des projets web/mobile autour d’un média local : Laravel, Flutter, MariaDB, Firebase, API, vidéo, notifications, jeux interactifs, etc.
Mon rôle est souvent à mi-chemin entre produit, architecture, développement et reprise de systèmes existants. Mon premier code date de... 1985 😄
Ma méthode ressemble à ceci :
- Je pars d’une vision fonctionnelle assez claire, mais pas toujours structurée J’ai souvent une intuition assez précise de ce que le produit doit faire, des flux utilisateurs, des contraintes métier, des cas limites. Par contre, cette vision peut être très panoramique. Avant, le risque était de partir trop vite dans tous les sens. Maintenant, j’utilise l’IA pour transformer cette vision en étapes exploitables.
- Je force tout à passer par une spécification Markdown Avant de coder, je demande généralement une spec technique en Markdown : objectifs, périmètre, architecture, endpoints, tables, contraintes, risques, définition du “done”, cas limites. Ce document sert ensuite de contrat entre moi, le code existant et le LLM de co-coding. Ce n’est pas un PRD marketing, plutôt une spec opérationnelle que je peux réellement donner à un outil ou à un développeur.
- Je découpe en petits chantiers verticaux J’évite de dire “refais toute l’app” ou “migre tout le backend”. Je préfère des blocs du type : Le but est d’avoir des incréments testables, pas un énorme chantier magique.
- migrer l’auth mobile vers une nouvelle API ;
- exposer tel endpoint Laravel ;
- remplacer une source Firebase ;
- documenter un module ;
- ajouter un garde-fou de sécurité ;
- écrire une migration Eloquent ;
- rendre un comportement rétrocompatible.
- Je considère l’IA comme un co-développeur très rapide, mais pas comme un décideur Je lui délègue volontiers :
- les squelettes de code ;
- les migrations ;
- les scripts ;
- les transformations répétitives ;
- la documentation ;
- les checklists ;
- les premiers diagnostics ;
- les refactorings encadrés.
- Par contre, je ne lui délègue pas aveuglément :
- les choix d’architecture critiques ;
- la sécurité ;
- la validation métier ;
- la mise en production ;
- les suppressions destructrices ;
- les migrations de données sans garde-fous.
- Je garde toujours une source de vérité claire C’est probablement le point le plus important dans mes projets récents. Quand il y a plusieurs systèmes (ancien backend, nouvelle API, app Flutter, Firebase, base MariaDB, ancien PostgreSQL, etc.), je cherche d’abord à définir qui est la source de vérité. Exemple typique : Laravel peut devenir la source API principale, pendant qu’un ancien système reste seulement une source éditoriale amont ou un système transitoire. Ça évite de bricoler des synchronisations implicites partout.
- Je documente pendant que je construis Je ne vois plus la documentation comme une tâche finale. Elle fait partie du dev. Quand je reprends un module, je commence par la doc : ça permet aussi de reprendre le contexte plus tard avec un LLM sans tout réexpliquer.
- le comportement actuel ;
- le comportement cible ;
- les fichiers concernés ;
- les commandes utiles ;
- les risques ;
- les tests à faire ;
- les décisions prises.
- Je reste très méfiant sur la partie “ça compile donc c’est bon” Le LLM accélère énormément la production de code, mais il ne remplace pas : Je dirais que l’IA accélère surtout les 60 premiers pourcents d’un chantier. Les 40 derniers (validation, durcissement, edge cases, prod) restent très humains.
- les tests réels ;
- la lecture des logs ;
- les essais sur environnement propre ;
- la vérification des permissions ;
- les contraintes de prod ;
- la compatibilité avec l’existant ;
- la compréhension des effets de bord.
Au final, ma méthode c’est moins “l’IA code à ma place” que :
>Je transforme une intuition produit en spec exploitable, je découpe en chantiers, je fais produire vite les briques répétitives, puis je reprends la main sur l’architecture, les arbitrages et la validation.
Je suis curieux de savoir si d’autres ici fonctionnent comme ça : documentation d’abord, co-coding encadré, specs Markdown, puis validation humaine stricte.
Et, point assez intéressant, tout ça repose chez moi sur deux abonnements relativement accessibles :
- ChatGPT Plus, à 20 $/mois, que j’utilise surtout pour réfléchir, structurer, challenger mes idées et préparer mes specs Markdown ;
- Google Antigravity IDE, via le forfait de base Google AI Pro à 21,99 €/mois, que j’utilise davantage pour le travail dans le code.
Pour Antigravity, il y a évidemment des quotas, mais je trouve que ce n’est pas forcément un mal. Quand je vois que j’ai déjà consommé la moitié de mon quota hebdomadaire, ça me force à ralentir : relire le code généré, vérifier la documentation produite, reprendre les décisions techniques, contrôler les diagrammes Mermaid, nettoyer ce qui doit l’être.
En fait, cette limite crée une sorte de garde-fou. Elle m’empêche de tomber dans le piège du “je continue à générer du code parce que ça va vite”.
Et soyons honnêtes : oui, il arrive que le LLM fasse n’importe quoi si on ne cadre pas assez. J’ai déjà eu des comportements destructeurs, y compris sur des bases de données. Donc chez moi, c’est sauvegardes DB versionnées, méthode Git stricte, commits fréquents, branches de travail et validation humaine avant toute opération sensible.
Au final, je ne vois pas ces outils comme des développeurs autonomes. Je les vois plutôt comme des accélérateurs très puissants, à condition de garder une méthode solide autour : specs claires, versioning, sauvegardes, relecture, tests et responsabilité humaine.
Vous avez mis en place des garde-fous similaires dans vos workflows IA ? Ou vous laissez l’agent coder plus librement ?
Vous avez trouvé d’autres méthodes efficaces pour éviter que le dev assisté par IA parte dans tous les sens ?
