La version longue.
Pour qui veut la profondeur technique — voici ce que chaque phase produit réellement, pourquoi elle existe et comment elle s'enchaîne à la suivante. Globalement : le pipeline est une chaîne d'artefacts où chaque phase prend en entrée un document de la phase précédente et produit un nouveau document que la phase suivante peut lire. Aucune passation orale. Pas de « je crois qu'on en a parlé au stand-up de mercredi ».
Allium — le drift comme donnée.
Allium est un langage d'interrogation : tu écris une spécification, puis une passe d'elicitation trouve les trous, les ambiguïtés et les incohérences. Elle produit des questions ouvertes auxquelles il faut répondre avant d'avancer. Plus tard, une passe de distillation compare le code fini à la spec — le drift remonte en trois catégories : spécifié-mais-non-implémenté, implémenté-mais-non-spécifié, et drift comportemental. Chaque élément reçoit une décision individuelle : corriger maintenant, defer (suivre dans la spec) ou dismiss avec raison. Pas de décisions de groupe pour « voir plus tard » — chaque finding a un propriétaire et une date.
TLA+ — des preuves, pas des tests.
Un test qui passe montre qu'une exécution a fonctionné. Il ne dit rien des exécutions que tu n'as pas testées. TLA+ modélise le système comme un espace d'états et fait un parcours exhaustif — le vérificateur de modèles TLC essaie toutes les séquences possibles d'événements et trouve les états où les invariants sont brisés. Pour la gestion d'affaires : un dossier peut-il être à la fois clos et en cours ? Pour SSE : que se passe-t-il si le client se reconnecte en plein milieu d'une mise à jour ? Pour l'idempotence : que se passe-t-il si la même clé d'idempotence arrive dans deux requêtes simultanées ? TLC répond mathématiquement, pas en probabilité.
Tests destructifs — six catégories.
Les tests fonctionnels vérifient que le chemin heureux marche. Les tests destructifs vérifient que le système ne s'effondre pas quand quelqu'un tente de le casser. Nous exécutons au moins huit scénarios destructifs par surface, répartis sur six catégories.
La validation d'entrée bombarde les champs avec des chaînes trop longues, des caractères invalides, des null et des valeurs vides. L'autorisation tente de lire et écrire des ressources que l'utilisateur ne possède pas. La catégorie injection injecte du XSS dans les champs texte et du SQL dans les paramètres de recherche. Les race conditions forcent deux clients à modifier la même ressource dans la même seconde. Les valeurs limites éprouvent longueurs maximales, comptes maximaux et pagination sur la dernière page. La corruption d'état envoie des modifications dans le mauvais ordre ou sur des ressources déjà supprimées.
Rien de tout cela n'est théorique. Chaque catégorie a attrapé de vrais bugs dans des systèmes en production que nous avons construits — avant qu'ils ne sortent.
Développement IA-augmenté — sans religion de l'IA.
Claude Code est utilisé comme outil, pas comme remplacement. Le pipeline ci-dessus n'est pas généré par IA — il est documenté, versionné et appliqué via des hooks déterministes. Les hooks bloquent le travail de feature sans spec, exigent une clarification avant le plan, lancent l'elicitation Allium avant l'implémentation et refusent de livrer une feature sans validation Playwright et TLA+. L'IA suit la méthode — elle ne l'invente pas. Résultat : la vitesse de l'IA avec une revue humaine sur les décisions d'architecture.
Cette méthode prend plus de temps la première semaine. Elle fait gagner des mois quand le système a un an.
