02 — Méthode d'ingénieur

02 — Méthode d’ingénieur

Objectif : apprendre la discipline qui différencie un développeur d’un ingénieur — spécifier, planifier, itérer, tester — et la faire appliquer par Opencode.

Un développeur écrit du code qui marche. Un ingénieur conçoit des systèmes qui tiennent dans le temps. L’IA écrit vite ; votre travail d’ingénieur est de lui donner la direction.

1. Écrire une bonne spécification

Avant de coder, décrivez le besoin comme si vous parliez à un développeur junior : contexte, comportement attendu, cas limites.

Mauvaise demande :

Ajoute une fonctionnalité de suppression.

Bonne demande :

Quand un utilisateur supprime une note :
- marque-la comme supprimée en base (soft delete, colonne deleted_at)
- ne l'affiche plus dans la liste principale
- crée un écran "Récemment supprimées" où l'utilisateur peut :
  - restaurer une note (remet deleted_at à NULL)
  - supprimer définitivement (hard delete)
- respecte le pattern existant dans @src/notes.ts

La qualité de la sortie dépend directement de la qualité de l’entrée. C’est la compétence n°1 de l’ingénieur IA.

2. Le cycle Plan → Build → Vérifier

Opencode met ce cycle à disposition nativement :

Plan (Tab)  →  Spécification + découpage en tâches
Build (Tab) →  Implémentation
Vérifier    →  Lancer les tests, relire le diff, /undo si besoin

Le cycle de travail d’ingénieur se répète à chaque incrément :

flowchart TD
    A[Spécifier<br/>contexte + comportement + cas limites] --> B[Planifier<br/>Plan mode : découpage en tâches]
    B --> C{Plan validé ?}
    C -- Non --> A
    C -- Oui --> D[Itérer<br/>Build mode : petit incrément]
    D --> E[Tester<br/>typecheck + tests + lint]
    E --> F{Tests verts ?}
    F -- Non --> D
    F -- Oui --> G[Relire le diff<br/>vous ou code-reviewer]
    G --> H{Modifs OK ?}
    H -- Non --> D
    H -- Oui --> I[Committer<br/>message clair]
    I --> J{Nouvelle étape ?}
    J -- Oui --> B
    J -- Non --> K[✔ Tâche terminée]
    style A fill:#eef2ff,stroke:#4f46e5,color:#312e81
    style B fill:#ecfeff,stroke:#0891b2,color:#164e63
    style D fill:#f5f3ff,stroke:#7c3aed,color:#4c1d95
    style E fill:#f0fdf4,stroke:#16a34a,color:#14532d
    style G fill:#fff7ed,stroke:#ea580c,color:#7c2d12
    style I fill:#fef2f2,stroke:#dc2626,color:#7f1d1d
    style K fill:#f0fdf4,stroke:#16a34a,color:#14532d

Conseils de planification

• Toujours passer par le Plan mode pour une tâche non triviale. Laissez Opencode poser des questions.
• Exigez un découpage. “Découpe ce plan en tâches indépendantes avec un critère de complétion pour chacune.”
• Révisez avant d’implémenter. Vous êtes le chef de projet ; Opencode est l’exécutant. S’il propose quelque chose de trop gros, réduisez le périmètre.

3. Le fichier AGENTS.md — votre mémoire de projet

AGENTS.md (créé par /init, au chapitre 01) contient ce que l’agent doit savoir en permanence : structure, commandes, conventions, pièges.

Un bon AGENTS.md inclut typiquement :

# Projet MonProjet

## Stack
- Frontend : React + TypeScript (Vite)
- Backend : FastAPI (Python)
- Base de données : PostgreSQL via SQLAlchemy

## Commandes
- `npm run dev` — serveur de dev
- `npm run test` — tests (Vitest)
- `npm run lint` — lint ESLint
- `npm run typecheck` — vérification TypeScript

## Conventions
- Tous les composants React sont en .tsx, camelCase pour les props
- Les erreurs API sont typées, jamais `any`
- Un test pour chaque nouvelle fonction utilitaire

## Pièges connus
- Ne jamais modifier src/config.ts sans valider avec l'équipe
- Le cache Redis invalide sur la clé `user:{id}:profile`

Méthode d’ingénieur : mettez à jour AGENTS.md après chaque découverte importante. C’est votre documentation vivante — et celle que l’IA consulte à chaque session.

Vous trouverez un exemple complet dans exemples/AGENTS.md.

4. Itérer par petites étapes

Les incréments courts sont plus sûrs, plus faciles à revoir, plus faciles à annuler.

Bon rythme :

1. "Ajoute le champ deleted_at au modèle Note, avec migration."   → build → tester
2. "Adapte la liste principale pour filtrer les notes supprimées." → build → tester
3. "Crée l'écran Récemment supprimées."                            → build → tester
4. "Ajoute les actions restaurer / supprimer définitivement."      → build → tester

Mauvais rythme : une seule grosse demande qui fait tout à la fois.

5. Tester systématiquement

Demandez à Opencode d’écrire les tests en même temps que le code — ou avant (TDD, voir le chapitre 05 et le skill d’exemple test-driven-dev).

# Après chaque modification significative :
npm run typecheck && npm run test && npm run lint

Un changement non vérifié n’est pas terminé. C’est le premier réflexe d’ingénieur à acquérir.

6. Relire avant de valider

Avant un commit, relisez le diff — soit vous-même, soit avec l’agent code-reviewer (voir chapitre 03).

git diff

Demandez ensuite à Opencode :

Passe en revue le diff et signale : bugs potentiels, cas limites,
fautes de sécurité, code mort. Propose des correctifs précis.

7. Le commit propre

Commitez de petites unités cohérentes, avec des messages clairs. Opencode peut rédiger le message :

Rédige un message de commit pour les changements en cours.

Récapitulatif — les 5 réflexes d’ingénieur

1. Spécifier avant de coder (contexte, comportement, cas limites).
2. Planifier en Plan mode avant d’implémenter.
3. Itérer par petits incréments vérifiables.
4. Tester chaque changement (typecheck + tests + lint).
5. Relire le diff avant de committer.

Passez au chapitre 03 — Agents pour apprendre à déléguer des rôles spécialisés.