Tech1 阅读

Le MVP n'est pas un compromis, c'est un ordre de développement plus intelligent.

En tant qu'ingénieurs, nous aimons naturellement « faire complet » : concevoir une architecture élégante, abstraire des composants génériques, mettre en place l'authentification, CI/CD, un système de design complet... Résultat : la date de mise en ligne est repoussée sans cesse.

La mentalité MVP (Minimum Viable Product) vous aide essentiellement à vérifier si une idée mérite d'être poursuivie à moindre coût.

Pour les développeurs, il ne s'agit pas « d'écrire du code bâclé », mais de « prendre les bonnes décisions d'ingénierie au bon moment ».

D'abord, clarifions : qu'est-ce qu'un MVP ?

Une définition plus formelle : un MVP est une version d'un produit avec un minimum de fonctionnalités, mais suffisante pour être livrée à de vrais utilisateurs et recueillir des retours pour valider des hypothèses.

Voici trois informations clés :

En une phrase : avec un minimum de code, déterminez une chose : est-ce que quelqu'un veut vraiment utiliser ce produit.

La pensée centrale du développement MVP

D'un point de vue ingénierie, on peut décomposer la pensée MVP en plusieurs étapes :

  1. Définir un « problème » à valider

    Par exemple : « Les utilisateurs sont-ils prêts à utiliser un outil de prise de notes minimal en ligne plutôt que de s'envoyer des messages sur WeChat ou par email ? »

  2. Ne conserver que les fonctionnalités nécessaires pour valider ce problème

    Créer une note, afficher la liste, en supprimer une — cela suffit.

  3. Utiliser le chemin le plus rapide pour implémenter

    Ce n'est pas forcément « la stack la plus tendance », mais celle que vous maîtrisez le mieux.

  4. Mettre en ligne dans un périmètre minimal, observer l'utilisation réelle

    Testez d'abord avec vos collègues, amis, avant de songer à une publication large.

  5. Itérer sur la base des données comportementales, pas sur des suppositions

    Observez si les utilisateurs reviennent, ne vous fiez pas à leurs « c'est super » polis.

Comparaison simple : deux voies courantes pour les ingénieurs

Voie non-MVP (celle que nous empruntons souvent) :

Voie MVP :

L'architecture pourra être améliorée plus tard, mais si personne ne veut l'utiliser, vous aurez construit une « ville fantôme » pour rien.

Pratique : créer un MVP de prise de notes avec Next.js

Prenons un « bloc-notes / mémo en ligne » comme exemple, et suivons la démarche MVP avec Next.js (App Router).

1. Définir le périmètre du MVP

Les besoins sont volontairement réduits :

Ce qui n'est pas fait pour l'instant :

Avec un tel périmètre, tout développeur familier avec React peut réaliser une version fonctionnelle en 1 à 2 jours.

2. Structure du projet et squelette

Créez un projet App Router en suivant la documentation officielle.

Dans le terminal :

bash
npx create-next-app@latest note-mvp
# ou choisissez TypeScript, App Router, etc.
cd note-mvp
npm run dev

Dans la structure des répertoires, le dossier app/ est central. [nextjs](https://nextjs.org/docs/app)

Organisation minimale :

3. Écrire une API minimale avec App Router

Dans app/api/notes/route.ts, utilisez d'abord un tableau en mémoire pour simuler le stockage (en production, vous pourriez passer à SQLite / Supabase, etc.).

ts
// app/api/notes/route.ts
import { NextResponse } from 'next/server'

type Note = {
  id: string
  content: string
  createdAt: string
}

let notes: Note[] = []

export async function GET() {
  return NextResponse.json(notes)
}

export async function POST(request: Request) {
  const { content } = await request.json()
  if (!content || typeof content !== 'string') {
    return new NextResponse('Invalid content', { status: 400 })
  }

  const note: Note = {
    id: crypto.randomUUID(),
    content,
    createdAt: new Date().toISOString(),
  }

  notes.unshift(note)
  return NextResponse.json(note, { status: 201 })
}

export async function DELETE(request: Request) {
  const { searchParams } = new URL(request.url)
  const id = searchParams.get('id')
  if (!id) {
    return new NextResponse('Missing id', { status: 400 })
  }

  notes = notes.filter((n) => n.id !== id)
  return new NextResponse(null, { status: 204 })
}

Ce code présente plusieurs points « perfectibles », par exemple :

Mais dans la phase MVP, cela suffit pour valider l'objectif : « quelqu'un veut-il écrire quelque chose et y revenir ? »

4. Écrire une page simple

Dans app/page.tsx, utilisez un Client Component pour gérer les interactions.

tsx
'use client'

import { useEffect, useState } from 'react'

type Note = {
  id: string
  content: string
  createdAt: string
}

export default function Home() {
  const [notes, setNotes] = useState<Note[]>([])
  const [input, setInput] = useState('')
  const [loading, setLoading] = useState(false)

  useEffect(() => {
    fetch('/api/notes')
      .then((res) => res.json())
      .then((data) => setNotes(data))
  }, [])

  async function handleAdd(e: React.FormEvent) {
    e.preventDefault()
    if (!input.trim()) return

    setLoading(true)
    try {
      const res = await fetch('/api/notes', {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify({ content: input.trim() }),
      })
      const note: Note = await res.json()
      setNotes((prev) => [note, ...prev])
      setInput('')
    } finally {
      setLoading(false)
    }
  }

  async function handleDelete(id: string) {
    await fetch(`/api/notes?id=${id}`, { method: 'DELETE' })
    setNotes((prev) => prev.filter((n) => n.id !== id))
  }

  return (
    <main style={{ maxWidth: 600, margin: '2rem auto', padding: '0 1rem' }}>
      <h1>Minimal Notes MVP</h1>

      <form onSubmit={handleAdd} style={{ marginBottom: '1rem' }}>
        <textarea
          value={input}
          onChange={(e) => setInput(e.target.value)}
          rows={3}
          style={{ width: '100%', marginBottom: '0.5rem' }}
          placeholder="Écrivez quelque chose..."
        />
        <button type="submit" disabled={loading}>
          {loading ? 'Enregistrement...' : 'Enregistrer'}
        </button>
      </form>

      <section>
        {notes.length === 0 && <p>Aucune note pour l'instant.</p>}
        {notes.map((note) => (
          <article
            key={note.id}
            style={{
              border: '1px solid #ddd',
              padding: '0.75rem',
              marginBottom: '0.75rem',
            }}
          >
            <p style={{ whiteSpace: 'pre-wrap' }}>{note.content}</p>
            <small style={{ color: '#666' }}>
              {new Date(note.createdAt).toLocaleString()}
            </small>
            <div>
              <button
                onClick={() => handleDelete(note.id)}
                style={{ marginTop: '0.25rem' }}
              >
                Supprimer
              </button>
            </div>
          </article>
        ))}
      </section>
    </main>
  )
}

Cette page est très « basique » : un textarea, un bouton, une liste.

Mais elle boucle déjà le cycle complet :

Du point de vue MVP, cela suffit pour le donner à 5-10 testeurs et observer leur comportement réel.

Quelles pensées MVP cet exemple Next.js illustre-t-il ?

En revenant sur cette implémentation, on peut voir :

Aucune bibliothèque de gestion d'état, framework UI ou service backend complexe supplémentaire.

Bien qu'utilisant le stockage en mémoire pour l'instant, le chemin d'API est déjà fixé ; passer à une base de données plus tard ne nécessite que de modifier l'implémentation dans la route.

« Quelqu'un est-il prêt à écrire une note courte dans un navigateur et à revenir la voir/supprimer au même endroit ? »

Pour un ingénieur familier avec Next.js, ce niveau MVP peut être complété et déployé sur Vercel en une journée.

À partir de ce point de départ, vous pouvez décider de la suite en fonction du comportement des utilisateurs, par exemple :

Erreur fréquente : prendre « la perfection technique » pour objectif

Dans les projets réels, beaucoup d'ingénieurs considèrent un tel MVP comme un « jouet temporaire » et ont du mal à l'accepter :

Deux considérations réalistes :

Le MVP ne renie pas la qualité d'ingénierie, mais place « l'ingénierie de haute qualité » après que le besoin a été prouvé valide.

Pour conclure : la mentalité MVP pour les ingénieurs

On peut voir la pensée MVP comme une forme de gestion des risques techniques :

Pour les développeurs expérimentés, une approche pratique consiste à :

Partager

Partager

Partager cet article.