Pourquoi nous avons créé une méthode pour arrêter de coder à l'aveugle

Le code n'est presque jamais le problème. Le problème, c'est ce qui n'a pas été décidé avant d'écrire le code.

Nous avons mis du temps à l'admettre. Pendant longtemps, notre réflexe sur un nouveau projet a été le même que celui de la plupart des devs et des créateurs solo : ouvrir l'éditeur, commencer à coder, et régler les questions de fond au fur et à mesure. Résultat : des allers-retours, des fonctionnalités reprises parce qu'un cas limite n'avait pas été anticipé, et — le pire — une sécurité pensée uniquement après le premier incident.

Ce n'est pas de la dette technique. C'est de la dette de conception. Et elle coûte bien plus cher qu'on ne l'imagine.

Le prompt flou produit un résultat flou

Avec l'arrivée des assistants IA dans le développement, ce problème s'est aggravé plutôt qu'atténué. Demander "code-moi une app de gestion de tâches" à une IA produit un résultat générique, parce que la demande l'était. L'IA ne devine pas les contraintes qu'on ne lui donne pas — elle comble les trous avec des choix par défaut, rarement les bons pour ton projet précis.

Le vrai levier n'est pas un meilleur prompt. C'est un meilleur cahier des charges, écrit avant de solliciter l'IA — ou avant de coder soi-même.

La méthode que j'ai fini par formaliser

Après plusieurs projets (dont Haloo et d'autres en cours), nous avons finis par extraire un pattern qui revenait à chaque fois : les mêmes catégories de décisions à prendre, dans le même ordre, pour n'importe quel type de projet — un outil CLI, une app mobile, un SaaS.

Nous avons formalisés ça sous le nom Project Blueprint : un catalogue de 26 documents organisés en 11 phases, de la vision produit aux principes d'ingénierie, en passant par l'architecture, la sécurité, l'IA et la qualité.

Le point important — et c'est celui qui change tout — : la méthode ne génère jamais les 26 documents par défaut. Un petit outil en ligne de commande n'a pas besoin d'un Design System. Une application mobile grand public a besoin d'une UX Bible dès le premier jour. La méthode sélectionne, fusionne ou écarte chaque document selon la nature réelle du projet, et documente pourquoi.

Concrètement, pour chaque document du catalogue, trois décisions possibles :

  • Inclure — le document répond à un besoin réel du projet
  • Fusionner — le besoin existe mais ne justifie pas un fichier séparé pour un projet de cette taille
  • Écarter — le document ne correspond à rien dans ce projet précis

Une règle ne se négocie jamais : la sécurité n'est jamais totalement écartée, même sur le plus petit des projets.

Le processus en 7 étapes

  1. Ingérer le brief — lire l'idée dans son intégralité, repérer sa langue
  2. Optimiser en spec de projet — restructurer le brief en objectif, public, contraintes, sensibilité des données
  3. Vérifier les manques — poser les questions essentielles, une seule fois, groupées
  4. Construire la matrice de sélection — inclure/fusionner/écarter, avec une raison
  5. Concevoir la structure de dossier — adaptée à ce qui a été réellement sélectionné
  6. Générer dans l'ordre de dépendance — vision → PRD → architecture → sécurité → IA → qualité → principes
  7. Livrer — un dossier complet, cohérent, prêt à guider le développement

Pourquoi on a fait un guide (+ une skill Claude)

Une fois la méthode rodée sur mes propres projets, la question s'est posée d'elle-même : pourquoi la garder pour moi ?

On a transformé tout ça en un guide PDF de 29 pages qui explique la méthode en détail, avec un catalogue complet des 26 documents, un prompt-cadre universel utilisable dans n'importe quel outil IA (ChatGPT, Gemini, peu importe), et une étude de cas réelle avec la matrice de sélection produite.

Et pour ceux qui utilisent Claude, notre équipe a encodé toute la méthode dans une skill installable en un clic : tu décris ton projet, elle construit la matrice de sélection, tu valides, elle génère le dossier complet — structure de fichiers réelle, pas juste du texte à recopier.

Pour qui c'est fait

  • Les fondateurs solo et petites équipes qui démarrent un projet
  • Les développeurs qui veulent déléguer du code à une IA en confiance, avec un vrai cahier des charges derrière
  • Toute personne qui veut arrêter d'improviser la conception et commencer avec une base solide

Le guide fonctionne avec ou sans Claude — aucune dépendance obligatoire à un outil précis.

→ Découvrir Project Blueprint

Contenu en français. Licence d'usage personnel et professionnel illimité.