Comment l'IA redéfinit la QA avec Speckit

Le métier de développeur est désormais augmenté par l'IA générative. Le vibe coding sauvage va vite, uniquement guidé par l'instinct de son humain qui n'a pas besoin d'écrire ses idées puisqu'il les développe aussitôt. En développement sur un nouveau projet (greenfield), ça va très vite.

Toutefois, des mois plus tard quand il faut faire évoluer le produit, l'équipe a changé. Les spécifications du produit sont absentes mais elles peuvent être rétrogénérées à partir du code par Claude Code, Cursor ou autre. Donc la nouvelle équipe peut à nouveau s'approprier le legacy et vibe coder sauvagement la suite. En refactoring d'un projet existant (brownfield)...ça va donc très vite aussi.

A priori donc, c'est suffisant pour être compétitif ?

J'ai testé Speckit, qui est l'un des framework de Harness Engineering en vogue, dont la prétention est d'apporter davantage de cadre et de prédictibilité dans le développement augmenté. Cet article décrit mon expérience sur le sujet.

Le niveau 1 : l'Acceptance Test Driven Development

Les tests d'acceptance qui traduisent l'acceptabilité du produit pour sa mise en service ne pourront pas être rétro-générés à partir du code, s'ils n'ont pas été écrits initialement alors ils sont perdus. Intuitivement on pourrait se dire que si, bien sûr, Claude Code peut rétro générer les tests et critères d'acceptation à partir du legacy. Mais c'est tomber dans un biais de confirmation : l'IA ne peut tester que ce qui est écrit, pas ce qui aurait du l'être. Toutes les règles implicites seront simplement ignorées.

Exemple : si un Product Owner a dit un jour que tous les écrans doivent être affichés en moins de 200 ms, le vibe codeur initial l'a sans doute respecté dans son formulaire d'une complexité maîtrisée. Le vibe codeur suivant lui (ou le même développeur 3 mois plus tard), s'appuiera sur le code de l'écran généré et ne s'empêchera pas de le complexifier à outrance parce que ça va vite et que rien ne l'interdit. Et aucun garde-fou n'empêchera l'appli d'aller jusqu'à la prod et d'échouer.

La spécification peut être rétrogénérée, oui et sans doute avec encore plus de détail qu'au terme d'une intervention humaine traditionnelle en début de projet. Mais les tests d'acceptance doivent être au centre de la stratégie de tests. C'est pas nouveau comme paradigme mais avec l'IA générative, l'Acceptance Test Driven Development (ATDD) devient accessible. L'investissement initial à consentir, autrefois rédhibitoire pour les Product Owners peut devenir quasi transparent désormais. Certains frameworks tels Speckit ou BMAD permettent de prendre de la hauteur pour passer de vibe-coder à architecte-développeur : on ne code plus à l'instinct, mais on structure des plans de développement pour maîtriser la reproductibilité des opérations. La spécification est promptée une fois, le plan d'implémentation et les tâches eux sont jetables (par exemple, un plan pour une implémentation Kotlin, et un plan de la même spécification pour Swift).

Les frameworks de développement comme Speckit, permettent d'automatiser une grande partie de l'approche ATDD. La charge cognitive des développeurs est ainsi réduite, leur intervention concentrée sur les décisions importantes. Vous promptez votre besoin, Speckit identifie ce qui est important et doit être testé, il génère et vous propose des tests d'acceptance, avant de s'intéresser au code de la feature. Son plan d'implémentation prévoit ensuite d'itérer sur le code tant que tous les tests ne sont pas passants.

Prenons l'exemple d'un produit basique et spécifions le avec Speckit :

/speckit.specify une application web de prise de rendez-vous entre professionnel et particulier.

S'il est paramétré pour, Speckit génère automatiquement un répertoire specs/001-pro-client-booking avec un fichier de spécifications structuré en User Stories et tests d'acceptance :

En tant que développeur je peux soit valider en l'état et passer au plan d'implémentation, soit modifier cette spécification pour préciser les tests et critères d'acceptation.

Le niveau 2 : la Constitution

Speckit introduit un principe fort de Harness Engineering : le mécanisme de constitution permet de définir les grands principes auxquels toute nouvelle demande devra souscrire automatiquement, pour toujours ou jusqu'à amendement de la constitution. Un harnais de sécurité, mais encore plus haut que les tests d'acceptance au sommet de la pyramide de tests. Car la promesse qui fait la différence avec ces derniers, c'est que l'IA est capable de censurer une évolution avant même de la développer, si elle détecte une violation d'un amendement. C'est différent des rules (Claude Code, Cursor...) car chaque constitution est propre au cycle de vie de son projet. [Edit : BMAD a depuis repris le principe dans son project-context.md]

Vérifions cela par l'exemple en continuant sur l'exemple précédent de l'application de prise de rendez-vous et inscrivons maintenant dans la constitution du projet le principe suivant, pour tout le cycle de vie du projet :

L'utilisateur ne doit jamais attendre plus de 200 ms le chargement d'un écran quel qu'il soit avant de pouvoir l'utiliser.

Ensuite, le skill de clarification permet d'identifier les incohérences fonctionnelles dans notre première spécification, pour combler les trous dans la raquette. Ce skill est d'une pertinence rare (surtout compte tenu du manque de consistance de ma spécification à ce stade). 5 questions me sont posées pour répondre aux questions les plus structurantes détectées par l'IA :

/speckit.clarify

Une fois les réponses aux 5 questions obtenues, la spécification est mise à jour automatiquement et un test d'acceptance a été généré pour assurer que jamais une évolution ne viendra charger au-delà de 200ms un écran de l'application, Speckit a même été agressif en précisant des minimas là où je n'avais rien spécifié :

On peut passer à la génération du plan d'implémentation :

/speckit.plan Frontend & Backend : Next.js 14+ (App Router) avec TypeScript

Base de données : PostgreSQL avec Prisma ORM (ou Supabase)

Styles & UI : Tailwind CSS + composants Shadcn/ui

Gestion d'état / Requêtes : TanStack Query (React Query) si nécessaire, ou Server Actions Next.js

Authentification : Auth.js (NextAuth) ou Clerk

Base de données : Gestion rigoureuse des fuseaux horaires (Timezones) et verrouillage des créneaux pour éviter la "race condition" (deux clients qui cliquent en même temps sur le même créneau).

Design : Mobile-first, épuré et accessible (composants Radix/Shadcn).

Performance : Chargement des créneaux optimisé (Lazy loading ou Server-side rendering des jours).

Le plan est généré :

Découpons ensuite le plan généré en tâches :

/speckit.tasks

Et enfin, implémentons :

/speckit.implement

Après mise en place et conf d'une base postgresql, l'application tourne :

Pause

6 mois. De bonnes vacances bien méritées pour l'équipe qui a mis en prod la v1.

6 mois plus tard, c'est une équipe v2 qui revient apporter une évolution majeure à notre application. Et que lui manque-t-il de plus important ? Je vous le donne Emile ? Un loader. Un bon gros loader.

Nouvelle équipe, nouvelle demande d'évolution :

/speckit-specify applique un look n feel années 80, dans un style synthwave. L'écran d'accueil doit afficher l'animation d'une cassette audio en lecture pendant exactement 1.5 secondes, dès le début du chargement de la page d'accueil avant de révéler les créneaux de RDV, afin d'ancrer notre identité visuelle dans l'esprit des utilisateurs. Ajoute des blagues en rapport avec les groupes des années 80 pour agrémenter notre loader

Speckit ne s'embête pas et ajoute une exception à la constitution (comment ça ?!)

Si on va plus loin sans trop lire ce que génère Speckit, on fonce dans le mur.

Niveau 3 : le méta-prompting

Bétonner la constitution

L'IA cherchera toujours à contourner la constitution voire l'amender elle-même, comme Donald pour un nouveau mandat en 2028. Si vous foncez comme un bourrin, nous l'avons vu : l'anomalie arrivera en production (et Donald au pouvoir).

Alors recommençons en rendant notre constitution plus robuste et rejouons notre scénario. Je rajoute ces lignes au fichier de constitution :

• L'utilisateur ne doit jamais attendre plus de 200 ms le chargement d'un écran quel qu'il soit.

• Gestion des conflits : Tout projet d'évolution entrant en conflit ou en tension avec un amendement existant doit être systématiquement rejeté. Il est strictement interdit d'interpréter, de contourner ou de forcer la validation d'une telle demande.

• Souveraineté humaine : Aucune modification de la Constitution ne peut être automatisée. Seul l'administrateur humain dispose du pouvoir exclusif d'approuver et d'appliquer un amendement.

• Blocage réglementaire : Toute demande exigeant une révision constitutionnelle préalable doit être bloquée immédiatement, avant même toute phase de génération de code.

Notons que ces 3 derniers principes sont très forts, et "mettent des limites à l'IA". Car oui, sans le 3e de ces principes par exemple, Speckit aurait trouvé la faille :

Un développeur a même traduit les guidelines énoncées par Andrej Karpathy (chercheur et membre fondateur d'OpenAI) dans des principes que l'on peut reprendre ici pour aller encore plus loin dans le méta-prompting.

Relançons ensuite notre spécification d'évolution :

/speckit-specify applique un look n feel années 80, dans un style synthwave. L'écran d'accueil doit afficher l'animation d'une cassette audio en lecture pendant exactement 1.5 secondes, dès le début du chargement de la page d'accueil avant de révéler les créneaux de RDV, afin d'ancrer notre identité visuelle dans l'esprit des utilisateurs. Ajoute des blagues en rapport avec les groupes des années 80 pour agrémenter notre loader

La spécification passe sans encombre...voyons la suite.

/speckit.plan

Notre demande est anticonstitutionnelle. Speckit le sait et nous bloque désormais.

La constitution a joué son rôle de harnais de sécurité et nous propose soit d'amender la constitution soit d'abandonner notre demande. Aucune ligne de code n'a été générée ni retouchée.

Amendons notre constitution :

"L'utilisateur ne doit jamais attendre plus de 3200 ms le chargement d'un écran quel qu'il soit"

Relançons la création du plan, puis son implémentation, qui passent logiquement cette fois sans encombre. Réglons même le timer à 3 secondes : ça passe toujours.

Synthèse

En tant que directeur de projet, j'ai souvent été confronté à ce scénario. Par exemple, des formules mathématiques vitales pour l'équilibrage du réseau électrique national définies lors du cadrage initial par des experts scientifiques insaisissables, dont les tests automatisés coûteux étaient programmés mais jamais complètement à jour par rapport au code. Le temps manquant, on préfère exécuter des tests manuels donc faillibles, plutôt que d'investir dans le développement et la maintenance des tests automatisés, et le risque explose. Le mécanisme de constitution présenté ici prouve qu'avec une approche simple mais rigoureuse, on peut sanctuariser la qualité et la réussite d'un projet tech complexe dans la durée.

Conclusion

Speckit comporte plusieurs avantages mais n'est pas parfait. Et c'est normal, de l'aveu de Github qui l'a créé, puisque l'outil est en développement. A l'usage on se rend compte notamment :

• Le cycle d'instructions à respecter est fastidieux, mais obligatoire pour ne pas risquer de désynchroniser spécifications et code. Cela parait utopique de conserver cette rigueur en cas d'urgence (coucou l'ano de prod du vendredi). Les spécifications et les tests ne reflètent alors plus le code et ne sont plus une source de vérité pour l'avenir.

• Speckit crée un nouveau répertoire à chaque prompt, contenant ses propres spécifications, plans d'implémentation, tâches. Pour garder une bonne lisibilité il faut une sacrée maturité au départ, et cela incite à retarder le démarrage des développements (coucou le cycle en V). Si on veut démarrer vite, l'arborescence des spécifications et tests devient illisible.

  

• Par ailleurs Speckit est efficace pour un Lonesome Hero Coder. Si on est plusieurs dans l'équipe, comment faire pour ne pas se marcher dessus ? Comment faire pour paralléliser le travail sans induire continuellement des conflits dans les spécifications et les tests ?

Nous tenterons d'apporter des réponses à ces enjeux dans le prochain article de la série !