4. Cadrer un projet

Transformer une idée floue en projet structuré et comprendre pourquoi le retour arrière est critique.

Intermédiaire Étape 4 sur 9

De l'idée au besoin

Une tâche ponctuelle, c'est "aide-moi à faire ça". Un projet, c'est "je veux construire quelque chose qui va durer". La différence : un projet a besoin de cadrage avant de commencer.

Cadrer, c'est répondre à 5 questions avant de toucher quoi que ce soit :

  ┌─────────────────────────────────────────────┐
  │  1. Quel problème je veux résoudre ?         │
  │  2. Pour qui ?                               │
  │  3. Quel est le résultat attendu ?            │
  │  4. Qu'est-ce qui ne sera PAS fait ?         │
  │  5. Comment saurai-je que c'est terminé ?    │
  └─────────────────────────────────────────────┘

Si tu ne peux pas répondre à ces 5 questions, tu n'es pas prêt à commencer. Et c'est normal — c'est là que l'IA peut t'aider à cadrer.

Demander à l'IA de cadrer

Au lieu de demander à l'IA une solution immédiate, demande-lui de t'aider à clarifier ton besoin :

Je veux [décris ton idée en 1-2 phrases].
Avant de me proposer une solution, pose-moi les
questions nécessaires pour comprendre :
- le problème exact que je veux résoudre
- pour qui c'est destiné
- le résultat attendu
- mes contraintes (temps, outils, budget)
- ce qui est hors de portée

L'IA va te poser 5 à 10 questions. Tu réponds. À la fin, tu as un besoin clair. Et l'IA a assez de contexte pour te proposer quelque chose d'utile.

Exemple Jean-Paul

Jean-Paul veut "automatiser le traitement des factures". Trop vague. Il demande à l'IA de le cadrer. L'IA pose : "Combien de factures par mois ? Quel format d'arrivée (email, PDF, papier) ? Où les stockes-tu ? Qui doit les valider ? Veux-tu un outil Excel ou autre chose ?" Jean-Paul répond. Au final : "Je reçois 50 factures par mois en PDF par email, je veux extraire le montant et le fournisseur dans un tableau Excel, avec un statut à valider manuellement."

Exemple Kevin

Kevin veut "créer un site web". L'IA pose : "Quel type de site (portfolio, blog, e-commerce) ? Quelle techno (HTML simple, React, WordPress) ? Quel hébergement ? Combien de pages ? Quel contenu ?" Kevin répond. Au final : "Un portfolio en HTML/CSS/JS simple, 3 pages (accueil, projets, contact), hébergé sur mon serveur Docker."

Les documents minimums

Pas besoin d'un dossier de 50 pages. Pour un petit projet, quelques notes suffisent :

  • Le besoin — ce que tu veux faire (les 5 questions ci-dessus)
  • Le fonctionnement actuel — comment tu faisais avant (si applicable)
  • Le résultat attendu — à quoi ça doit ressembler
  • Les étapes — découpées en morceaux (voir page 5)
  • Les problèmes connus — ce qui ne marche pas encore
Pour Jean-Paul : un document Word ou un fichier texte suffit. Pas besoin d'outils complexes. L'important c'est d'avoir écrit le besoin avant de commencer.

Le retour arrière : pourquoi c'est critique

Voici la leçon la plus importante de ce tutoriel. Tout le reste peut s'adapter, mais celle-ci non.

La sandbox — la casse : Un jour, j'ai modifié un fichier dans un projet sans faire de sauvegarde d'abord. L'IA m'avait donné une modification qui cassait tout. Pas de Git, pas de copie, pas de retour arrière. Le projet était mort. J'ai dû tout recommencer. C'est ce jour-là que j'ai compris : avant de laisser l'IA toucher à quoi que ce soit, tu dois pouvoir revenir en arrière.

Le retour arrière, c'est la possibilité de dire "annule tout, reviens à la version d'avant". Sans ça, une modification ratée peut détruire des heures de travail.

Comment faire un retour arrière

Pour Jean-Paul (non-dev) :

  • Copie datée : avant de modifier un fichier, fais une copie nommée "factures_2026-01-15.xlsx". Si ça casse, tu reviens à la copie.
  • Historique OneDrive ou SharePoint : si tu utilises Office 365, les versions sont conservées automatiquement. Apprends à restaurer une version antérieure.
  • Règle d'or : jamais tester une macro directement sur l'unique fichier métier. Toujours sur une copie.

Pour Kevin (dev) :

  • Git : c'est le filet de sécurité standard en dev. Chaque "commit" est une photo de l'état du projet. Si une modification casse tout, tu reviens au commit d'avant. Pour apprendre Git, cherche un tuto en ligne — c'est un sujet à part entière.
  • Copie du dossier : si tu ne veux pas de Git, copie ton dossier de projet avant de modifier. C'est basique mais ça marche.
La règle absolue : quel que soit ton niveau, quel que soit l'outil, avant de demander à l'IA de modifier quelque chose, assure-toi de pouvoir revenir en arrière. Une copie datée, un commit Git, un export — peu importe. Mais assure-toi que c'est fait.

Découper en étapes

Un projet, c'est trop grand pour le faire d'un coup. La méthode : découper en étapes. Une étape (ou "milestone"), c'est :

  • Un objectif — ce que cette étape doit accomplir
  • Un périmètre — ce qui est dans l'étape et ce qui n'y est pas
  • Un résultat visible — comment tu sais que l'étape est finie
  • Un moyen de vérifier — comment tu testes que ça marche

Le détail de comment construire et valider des étapes est dans la page 5.

Définir "terminé"

Une étape est terminée quand :

  • Le résultat existe (ce n'est pas une promesse, c'est réel)
  • Il fonctionne sur les exemples prévus
  • Les cas importants sont vérifiés (cas normal, cas limite, cas d'erreur)
  • On peut revenir en arrière (copie datée ou commit)
Pour Jean-Paul : "terminé" veut dire que la macro marche sur ton fichier de test, que tu as vérifié le résultat sur 10 lignes, et que tu as une copie du fichier d'avant au cas où.

Mon expérience sandbox

La sandbox — le début de la documentation : Après la casse, j'ai commencé à documenter mes projets. Très simple au début : un fichier texte avec "ce que je veux faire", "ce qui marche", "ce qui ne marche pas". Pas de structure complexe. Juste écrire avant de coder. C'est devenu un réflexe : si je ne peux pas écrire le besoin en 5 lignes, c'est que je n'ai pas compris ce que je voulais.
← Étape 3 : vérifier et itérer Étape 5 : milestones, tests et versions →