DEV Community: Olivier

Découper une app métier en tranches livrables (et ne plus jamais faire de tunnel)

Olivier — Sun, 19 Jul 2026 17:47:59 +0000

Le tunnel de trois mois est le meilleur moyen de rater une application métier.

On cadre, on développe, on montre à la fin. Et à la fin, l'utilisateur dit la phrase qui coûte cher : « ah, mais nous on ne fait pas comme ça. »

Voici le découpage qu'on utilise pour éviter ça. Rien de révolutionnaire, mais quelques règles précises qui changent le résultat.

La règle de la tranche verticale

Une tranche livrable traverse toute la pile : base de données, logique, interface. Elle est utilisable de bout en bout par un vrai utilisateur.

C'est l'inverse du découpage par couche, où l'on fait « toute la base » puis « toute l'API » puis « tout le front ». Ce découpage-là ne produit rien de testable avant la fin.

❌ Semaine 1 : le schéma complet de la base
❌ Semaine 2 : toutes les routes API
❌ Semaine 3 : tous les écrans

✅ Semaine 1 : créer une commande et la voir dans une liste — écran compris
✅ Semaine 2 : la modifier et changer son statut
✅ Semaine 3 : la recherche et les filtres

Après la première semaine, quelqu'un peut ouvrir l'outil et faire quelque chose de réel. C'est là que remontent les vrais retours.

Le format de spec qui tient en un fichier

Chaque tranche a un fichier. Toujours la même structure, et elle sert autant à l'équipe qu'à l'assistant de code.

# Tranche 03 — Changement de statut d'une commande

## Ce que l'utilisateur peut faire
Ouvrir une commande, passer son statut de "en préparation" à "expédiée",
et voir qui l'a changé et quand.

## Règles métier
- Seuls les rôles `préparateur` et `admin` peuvent changer un statut.
- Un retour en arrière est interdit sauf pour `admin`.
- Chaque changement écrit une ligne dans `commande_historique`.

## Hors périmètre (important)
- Pas de notification e-mail (tranche 07).
- Pas d'export (tranche 09).

## Fini quand
- [ ] Un préparateur change un statut et voit l'historique se remplir.
- [ ] Un commercial n'a pas le bouton.
- [ ] Un retour en arrière est refusé avec un message clair.

La section Hors périmètre est celle qui fait le plus de travail. Elle empêche le glissement de périmètre, qui représente couramment 30 à 50 % de charge supplémentaire sur un projet mal tenu.

La section Fini quand évite l'autre classique : le désaccord sur ce que « terminé » veut dire.

Pourquoi ce format marche bien avec un assistant de code

On travaille avec Claude Code au quotidien. Ce format de fichier est celui qui donne les meilleurs résultats, pour une raison simple : un assistant échoue surtout quand le contexte est implicite.

Les règles métier écrites noir sur blanc (« un retour en arrière est interdit sauf admin ») produisent du code correct du premier coup. Les mêmes règles laissées dans la tête du chef de projet produisent du code plausible et faux.

Le « Hors périmètre » a un effet secondaire utile : il empêche l'assistant d'anticiper. Sans cette section, il ajoute spontanément une notification e-mail parce que ça semble logique — et vous héritez d'un code que personne n'a demandé, ni relu.

Un point sur lequel on ne transige pas : les critères de « Fini quand » deviennent des tests avant d'être considérés comme validés. Environ 45 % du code généré par IA contient au moins une vulnérabilité selon les analyses publiées en 2026. Ce chiffre ne condamne pas l'outil, il rappelle juste où mettre la relecture humaine.

L'ordre des tranches n'est pas neutre

On classe toujours dans cet ordre :

La tranche qui prouve l'usage. Celle qui, si elle ne convainc pas, invalide le projet entier. Elle passe en premier, quand le budget est encore intact.
Les tranches à risque technique. Intégration avec un système existant, import de données sales, API tierce mal documentée. Jamais à la fin.
Le confort. Filtres, exports, tableaux de bord. Utiles, mais aucun projet ne meurt de leur absence en semaine 4.

L'erreur fréquente est de commencer par l'authentification et l'administration des comptes, parce que c'est « la base ». C'est trois semaines avant de montrer quoi que ce soit d'intéressant. Une authentification minimale suffit largement au départ.

Ce que ça change concrètement

Le bénéfice n'est pas la vitesse brute. C'est que l'erreur de cadrage se paie en une semaine au lieu de trois mois.

Sur une app métier standard, ça donne une première version utilisable en 6 à 10 semaines, avec des retours utilisateurs dès la deuxième.

Et surtout : le jour où le client dit « nous on ne fait pas comme ça », il le dit assez tôt pour que ça ne coûte presque rien.

On détaille les étapes complètes d'un projet, les délais et les budgets réels ici : créer une application sur mesure.

J'ai automatisé la production d'articles SEO avec Claude Code — et le plus important, c'est le garde-fou

Olivier — Sun, 19 Jul 2026 05:42:07 +0000

Google a effacé jusqu'à 80 % du trafic de sites qui publiaient du contenu IA en masse. C'est le motif scaled content abuse.

On voulait quand même automatiser la production d'articles. La question n'était donc pas « comment produire vite », mais « comment empêcher la machine de publier de la bouillie ».

Voilà l'architecture qu'on a retenue, et le morceau de code qui compte vraiment.

Le pipeline

Six étapes, chacune tenue par un agent Claude Code spécialisé avec son propre contexte :

1. Chasseur      → mine les mots-clés (questions réelles, faible concurrence)
2. Cartographe   → lit la page 1 Google, relève les questions traitées
3. Rédacteur     → écrit selon un guide de voix versionné
4. Éditeur ⛔    → contrôle qualité, BLOQUE si en dessous du standard
5. Générateur    → markdown → HTML + JSON-LD + sitemap + RSS
6. Publication   → déploiement + ping IndexNow

L'étape 4 est la seule qui compte vraiment. Sans elle, on a juste une ferme de contenu qui se fait désindexer.

Le garde-fou, en code

L'erreur classique, c'est de demander à un LLM « est-ce que cet article est bon ? ». Un modèle qui juge sa propre production est complaisant.

On a donc mis un script déterministe. Pas d'IA, pas d'opinion, des mesures :

const R = {
  minWords: 700,                    // en dessous = contenu mince
  introMin: 250, introMax: 1400,    // zone "answer-first"
  minH2: 3,                         // structure
  minFaq: 3,                        // schema FAQPage
  titleMax: 70,                     // au-delà, Google tronque
  descMin: 110, descMax: 175,
  banned: [                         // formules bannies par la charte
    "dans le monde d'aujourd'hui",
    "il est important de noter",
    "en conclusion",
  ],
};

Et les vérifications qui font sortir le script en code 1 :

// frontmatter complet
for (const k of R.required)
  if (!meta[k]) err(`frontmatter: "${k}" manquant`);

// substance réelle
const words = body.replace(/[#*>|_`\-]/g, ' ').split(/\s+/).filter(Boolean).length;
if (words < R.minWords)
  err(`${words} mots (min ${R.minWords})`);

// liens internes valides — un lien mort et ça ne passe pas
for (const m of body.matchAll(/\]\((\/[a-z0-9-]+)\/\)/g))
  if (!allSlugs.includes(m[1].slice(1)))
    err(`lien interne cassé: ${m[1]}`);

// formules interdites
for (const b of R.banned)
  if (body.toLowerCase().includes(b))
    err(`formule interdite : « ${b} »`);

Le script de publication l'appelle en premier :

set -e
node check.mjs      # ⛔ sort en 1 → tout s'arrête ici
node build.mjs
wrangler pages deploy dist --project-name=…
node indexnow.mjs

set -e + code de sortie 1 = la publication est structurellement impossible si un article ne passe pas. Pas de « on verra », pas d'exception.

Ce que le garde-fou a attrapé dès le premier passage

Sur nos trois premiers articles, écrits pourtant avec soin :

3 meta descriptions trop longues (180 à 214 caractères). Google les aurait tronquées. Invisible à l'œil nu, évident pour le script.
Un lien interne cassé après un changement d'architecture d'URL.

Aucun humain relisant à 23h n'aurait vu ça.

Les pièges rencontrés

Le LLM juge mal son propre travail. D'où le script déterministe. L'IA écrit, le code mesure.

Le fuseau horaire. new Date('2026-07-17T00:00:00Z').toLocaleDateString('fr-FR') affichait le 16 juillet. Il faut forcer timeZone: 'UTC' — sinon toutes les dates de publication décalent d'un jour.

Le résidu de build. Un dossier oublié dans le répertoire de déploiement a mis en ligne un site entier au mauvais endroit. Depuis, le script de build est le seul à écrire dans ce dossier, et on vérifie son contenu avant chaque envoi.

Le calibrage des règles. La première version mesurait le « premier paragraphe » pour vérifier la réponse directe. Avec un style à paragraphes courts, elle criait au loup en permanence. On mesure maintenant le bloc entier avant le premier ##.

Ce que je retiens

La partie difficile n'était pas de faire écrire l'IA. C'est devenu trivial.

La partie difficile, c'est de rendre la médiocrité impossible à publier. Un seuil chiffré, un code de sortie, et la discipline de ne jamais le contourner.

L'autre chose : le volume ne va pas sur le domaine principal. Deux à trois articles par semaine, pas trente. Le volume part sur des plateformes à forte autorité — comme celle-ci. On automatise ce qu'on possède, on soigne à la main ce qu'on emprunte.

On est un studio de développement. On construit des applications sur mesure et on documente ce qu'on apprend en le faisant. Si l'architecture complète vous intéresse, elle est détaillée sur notre blog.