Guide Maifady — tutoriel pratique

Scénario

Tu codes depuis 1h, tu veux commit. Avant git commit, tu veux un avis pro en 30 secondes.

Tu tapes

git add .

›@code-reviewer-lite review mes changements stagés

Tu obtiens

# Code review — 4 files, 2 findings

## P0 (blocking)
1. **AuthController.php:34** — Password loggué en clair
   Fix: ne JAMAIS logger le password.

## P1 (fix before merge)
2. **AuthController.php:18** — Pas de rate limit sur /login
   Fix: ajouter le RateLimitMiddleware.

Scénario

Tu as fini une grosse PR qui ajoute la facturation. Tu veux te faire reviewer par un senior virtuel avant le collègue.

Tu tapes

›@code-reviewer-pro review ma branche feature/billing vs main,
focus sur design et perf

Tu obtiens

Rapport détaillé avec sections "Design", "Performance", "Concurrence", "Observabilité", "Dette". Plus des questions ouvertes.

Scénario

Tu lances ton SaaS la semaine prochaine. Tu veux un audit sécu complet avant launch.

Tu tapes

›@security-auditor audit complet. Focus :
- src/auth/ (login, signup, password reset)
- src/api/ (endpoints publics)
- secrets potentiellement hardcodés

Tu obtiens

# Audit sécurité — 8 findings

## CRITICAL (1)
### 1. SQL injection in password reset
- Location: src/auth/PasswordReset.php:42
- Exploit: POST /password-reset avec email="' OR 1=1--"
- Impact: pre-auth full account takeover.
- Fix: prepared statement.

## HIGH (3)...

Scénario

Une fonction de 240 lignes que personne ne comprend. Tu veux la nettoyer sans rien casser.

Tu tapes

›@refactor-assistant cette fonction processOrder() fait 240 lignes.
Propose un plan de refactor en plusieurs étapes safe.

Tu obtiens

## Refactor plan — 5 étapes safe

### Étape 1 : Extract validateOrderInput()
### Étape 2 : Extract calculatePricing()
### Étape 5 : processOrder() devient un orchestrateur de 30 lignes

Scénario

Tu reprends un projet legacy démarré il y a 4 ans. Tu veux la liste de ce qui peut dégager.

Tu tapes

›@dead-code-finder scan le repo. Distingue :
- code mort certain
- probablement mort (à confirmer)
- imports inutilisés
- TODOs > 1 an

Tu obtiens

# Dead code report — 47 findings

## Confident (safe to remove) — 14 items
## Likely (please confirm) — 18 items
## Unused imports — 11 items
## Stale TODOs — 4 items

Scénario

Ton code devient "complexe" mais tu ne sais pas où précisément.

Tu tapes

›@complexity-analyzer top 10 hot spots, ranked par complexité cognitive.
Pour les 3 pires, propose un plan de décomposition.

Tu obtiens

| Function        | File:line        | CC | Cog | LOC |
|-----------------|------------------|----|-----|-----|
| renderDashboard | Dashboard.tsx:42 | 28 | 52  | 187 |
| processWebhook  | Webhook.php:118  | 24 | 47  | 161 |

## Top 3 — plan de décomposition
### 1. renderDashboard (cog 52)
- Extraire useDashboardData() (hook)
- Extraire 3 sous-composants
- renderDashboard devient orchestrateur ~30 lignes

Scénario

Ton dashboard met 4.2 secondes. Une requête sur orders (4M lignes).

Tu tapes

›@sql-optimizer cette requête prend 4.2s :

SELECT o.*, u.email FROM orders o
JOIN users u ON u.id = o.user_id
WHERE o.status = 'pending' AND o.created_at > NOW() - INTERVAL '7 days'
ORDER BY o.created_at DESC LIMIT 50;

Postgres 15. Voici les schemas + EXPLAIN ANALYZE :
[colle]

Tu obtiens

## Diagnosis
Seq scan sur orders (4M rows). Index manquant.

## Index recommendation
CREATE INDEX idx_orders_status_created ON orders (status, created_at DESC)
WHERE status = 'pending';

## Expected impact
Seq scan (4.2s) → Index Scan (4-8 ms) — ~500× plus rapide

Scénario

Tu démarres une app de gestion de tâches. Schéma DB en 5 minutes, fait correctement.

Tu tapes

›@schema-designer schéma pour app de tâches :
- Users, Projets, Tâches (titre, due, statut, priorité)
- Tags M-N sur tâches
- Commentaires + historique

Cible : MariaDB 11. Multi-tenant.

Tu obtiens

6 CREATE TABLE complets, types adaptés (VARCHAR(320) emails, BIGINT IDs), indexes FK, CHECK constraints, soft delete. Plus l'ordre de migration.

Scénario

Ajouter colonne phone NOT NULL UNIQUE sur users. 5M lignes. Prod live.

Tu tapes

›@migration-writer ajoute phone VARCHAR(20) NOT NULL UNIQUE à users.
5M rows, MariaDB 11, prod live. Plan en plusieurs migrations safe.

Tu obtiens

## Plan en 4 migrations

### 023 — Add column nullable (instant)
ALTER TABLE users ADD COLUMN phone VARCHAR(20) NULL;

### 024 — Backfill en chunks (script séparé)
### 025 — Add UNIQUE index (online)
### 026 — Add NOT NULL constraint (après backfill 100%)

Scénario

API Python consomme 4 GB. Démarrage : 200 MB. 1h plus tard : 4 GB. Memory leak.

Tu tapes

›@perf-profiler API Flask en prod, RAM 200MB → 4GB en 1h.
Outils, hypothèses prioritaires ?

Tu obtiens

## Suggested measurement
1. memray (sampling, no code change)
2. py-spy snapshot

## Hypothesis ranking
1. Cache sans éviction — 60%
2. Connexions DB session leak — 25%
3. Logging handlers — 10%

Scénario

Tu viens d'écrire calculatePrice(items, discount). Tu veux les tests générés.

Tu tapes

›@test-generator génère les tests pour calculatePrice() dans src/pricing.ts.
Couvre : happy, panier vide, discount négatif, discount > 100%, prix négatif.

Tu obtiens

describe('calculatePrice', () => {
  test('returns 0 for empty cart', () => {
    expect(calculatePrice([], 0)).toBe(0);
  });
  test('applies discount correctly', () => {
    expect(calculatePrice([{price:100,quantity:2}], 10)).toBe(180);
  });
  test('throws on negative discount', () => {
    expect(() => calculatePrice([], -5)).toThrow();
  });
});

Scénario

Flow "signup → vérif email → onboarding". Tu veux un test E2E en CI.

Tu tapes

›@e2e-test-writer test Playwright pour le journey :
1. /signup → fill + submit
2. Page confirmation
3. Clic email (API /test/last-email)
4. /onboarding → /dashboard avec "Welcome"

Tu obtiens

Fichier tests/e2e/signup.spec.ts avec locators getByLabel, getByRole, auto-waiting, cleanup afterEach.

Scénario

Repo à 32% coverage. Passer à 70% sans tests bidons.

Tu tapes

›@coverage-improver repo TypeScript + Vitest à 32%.
Identifie 5 gaps les plus impactants.

Tu obtiens

## Top 5 gaps prioritaires
1. src/api/users.ts — 0%, API publique
2. src/billing/invoice.ts — 8%, business critical
3. src/auth/passwordReset.ts — 15%, security
4. src/utils/dateFormatter.ts — 0%, widely used
5. src/notifications/emailQueue.ts — 22%, error paths

## Expected new coverage : ~58%

Scénario

4 fichiers stagés. Tu allais taper git commit -m "fix stuff". Stop.

Tu tapes

git add .

›@commit-message-writer

Tu obtiens

fix(auth): prevent timing attack on password verification

The previous compare() used a string equality check that returned
early on first mismatch, leaking timing information.

Replace with hash_equals() which is constant-time.

Refs: #SEC-1234

Scénario

Tu reprends un projet sans README.

Tu tapes

›@readme-generator analyse le repo et écris un README.md complet.
Langue : français.

Tu obtiens

Un README avec titre + description, stack détectée, quick-start (commandes réelles), variables d'env, tests, licence. Aucune section bidon.

Scénario

Projet Next.js + Supabase + Stripe. Sans oublier le .env.local.

Tu tapes

›@gitignore-generator Next.js + Supabase + Stripe.

Tu obtiens

# --- Node ---
node_modules/
# --- Next.js ---
.next/
# --- Env / secrets ---
.env
.env.local
!.env.example
# --- Stripe / Supabase / OS / IDE ---

Scénario

Rédiger un ADR : Postgres vs MongoDB.

Tu tapes

›@tech-writer ADR : on choisit Postgres plutôt que MongoDB.
Raisons : 80% relations ACID, équipe Postgres, reporting SQL, < 100M docs.

Tu obtiens

ADR formaté Context / Options / Decision / Consequences / Revisit if. Tradeoffs honnêtes.

Scénario

API Express, 25 endpoints. Aucune doc.

Tu tapes

›@api-doc-generator doc markdown pour tous les endpoints dans src/routes/.
Inclus : path, méthode, body, response, auth, codes d'erreur.

Tu obtiens

Un docs/api.md basé sur le code réel. Endpoints sans docblock listés en "manque de doc" plutôt qu'inventés.

Scénario

Projet React de 2019. Class components partout. Tu veux moderniser sans casser.

Tu tapes

›@react-modernizer migre Dashboard.tsx (Class) vers function + hooks.
Préserve l'API publique. Tests verts.

Tu obtiens

## Avant : Class, 187 lignes
## Après : Function + hooks, 124 lignes

## Mapping
- this.state → useState (4 hooks, un par concern)
- componentDidMount → useEffect([], ...)
- this.refs.input → useRef

## Subtle behavior changes
- useEffect runs after paint. Impact ici : aucun.

Scénario

Formulaire signup qui marche à la souris. Ton CEO veut "accessible pour le marché EU".

Tu tapes

›@accessibility-auditor audit src/pages/Signup.tsx contre WCAG 2.2 AA.
Fixes concrets.

Tu obtiens

## CRITICAL (2)
1. **Signup.tsx:34** — Input email sans label
   WCAG 1.3.1 + 4.1.2 — bloque les screen readers.
   Fix: <label htmlFor="email">Email</label>

2. **Signup.tsx:88** — Bouton "X" sans nom accessible
   Fix: <button aria-label="Fermer">X</button>

## HIGH (3)... ## MEDIUM (4)...

Scénario

Site charge en 4 secondes sur 4G.

Tu tapes

›@bundle-analyzer analyse mon bundle Next.js.
Top 5 contributeurs gzippés + réductions concrètes.

Tu obtiens

| Module    | Gzipped | Note                    |
|-----------|---------|-------------------------|
| moment    | 71 KB   | → dayjs (-60 KB)        |
| lodash    | 38 KB   | tree-shake (-25 KB)     |
| chart.js  | 28 KB   | lazy load (-28 KB)      |

## Expected saving : -143 KB (-29%)

Scénario

App de réservation de salles. API design avant de coder.

Tu tapes

›@api-designer API REST pour réservation de salles.
Resources : Users, Rooms, Bookings. Bearer JWT. Multi-tenant.

Tu obtiens

Doc Markdown : ressources, endpoints, codes HTTP, format d'erreur, pagination cursor, versioning /v1/, auth.

Scénario

API Node existante. Tu veux Swagger sans rédiger à la main.

Tu tapes

›@openapi-generator analyse src/routes/ et génère openapi.yaml.

Tu obtiens

Un docs/openapi.yaml : paths, schemas TypeScript, responses, auth, examples. Tu balances dans Swagger UI → doc interactive.

Scénario

Monolithe Rails 8 ans, 200k lignes. L'équipe dit "il faut microservices". Tu doutes.

Tu tapes

›@microservices-architect analyse. Rester monolithique ou découper ?
Équipe : 6 devs. Pas de scaling pain. 50k MAU.

Tu obtiens

## Recommandation
**Reste modular monolith.**

## Pourquoi
- < 8 devs → coûts ops microservices > bénéfices.
- Aucun pain de scaling.
- Migrer = ralentir 6 mois pour résoudre un problème inexistant.

## Plan : Modular monolith
1. Modules avec frontières claires.
2. Pas d'imports cross-module sauf via API.
3. Extraction future = facile.

Scénario

Image Docker fait 1.2 GB. Pull lent.

Tu tapes

›@dockerfile-optimizer optimise mon Dockerfile.
Node.js 20 + Next.js. Image actuelle : 1.2 GB.

Tu obtiens

Dockerfile multi-stage, base node:20-alpine, RUN collapsés, USER appuser. ~180 MB au lieu de 1.2 GB.

Scénario

Première app sur K8s. Tu veux du vrai, pas du "Hello World".

Tu tapes

›@kubernetes-yaml-writer manifests pour Node.js :
- image : myregistry/myapp:v1.2.3, port 3000
- env : DB_HOST, DB_PASS (secret)
- 3 replicas, autoscale 3→10 sur CPU 70%
- Ingress https sur api.myapp.com
- runAsNonRoot, readonly FS

Tu obtiens

6 fichiers YAML avec maxUnavailable: 0, resources, probes, runAsNonRoot, capabilities drop ALL, PDB minAvailable: 2.

Scénario

Nouveau projet AWS. Tout en IaC dès le jour 1.

Tu tapes

›@terraform-writer setup AWS :
- VPC 3 AZs
- ECS Fargate
- RDS Postgres single-AZ
- ALB devant ECS
- Route 53 pour api.myapp.com
- State remote S3 + DynamoDB lock

Tu obtiens

Structure modules + envs prête à terraform init. Encryption partout, IAM least-privilege, SG verrouillés.

Scénario

Prompt extraction facture {vendor, date, total}. 30% du temps ça rate.

Tu tapes

›@prompt-engineer ce prompt rate 30% du temps :

"Tu es un assistant qui extrait les données d'une facture..."

Améliore-le.

Tu obtiens

## Diagnostic
- Pas de format strict → improvisation
- Pas d'exemple → hallucination
- Pas de gestion "champ manquant"

## Rewrite
You are an invoice data extractor. Output STRICT JSON.

<output_format>
{"vendor":"string|null","date":"YYYY-MM-DD|null","total":"number|null"}
</output_format>

<rules>
- If field not clear, output null. Never guess.
</rules>

<example>
Input: "ACME Corp, March 15 2026, $1,234.56"
Output: {"vendor":"ACME Corp","date":"2026-03-15","total":1234.56}
</example>

Scénario

Modèle de prédiction churn en prod, première fois. ML OK, MLOps non.

Tu tapes

›@ml-pipeline-architect architecture pour XGBoost churn :
- 50k clients, inférence batch quotidienne
- Données Postgres, cloud AWS
- 1 data scientist + 2 backend devs, zéro MLOps

Tu obtiens

Architecture stage par stage (ingestion → features → training → eval → deploy → monitoring), stack (MLflow, Airflow), alternatives selon complexité, 3 risques premiers.

Scénario

Regex héritée que personne ne comprend. Tu veux savoir avant d'y toucher.

Tu tapes

›@regex-explainer dans validators/email.js, personne ne sait :

/^[^\s@]+@[^\s@]+\.[^\s@]+$/

Tu obtiens

## Summary
Email basique : texte sans espace ni @, @, texte, point, texte.

| Token   | Means                       |
|---------|-----------------------------|
| ^       | début                       |
| [^\s@]+ | un+ caractères ni @ ni espace |
| @       | @ littéral                  |
| \.      | point littéral              |

## Matches
- user@example.com ✓
## Does NOT match
- user@example (manque le .)
- user @example.com (espace)

## Gotchas
- Très permissive. "a@b.c" passe.
- Pour valider vraiment : email de confirmation.