Spec-Driven Development : la méthode IA EloNeva
En résumé
- EloNeva applique une démarche de Spec-Driven Development : la spécification devient la référence du projet.
- L'humain valide les étapes clés : revue de la spec (aidée par l'IA), validation du plan et review de la Pull Request, sauf automatisation prévue avec le client.
- Chaque exigence reste traçable dans GitHub jusqu'aux tickets, au code, à la CI et aux tests qui prouvent son respect.
EloNeva utilise le SDD et c’est ce qui fait la différence
Chez EloNeva, nous utilisons une démarche de Spec-Driven Development, ou SDD, pour encadrer le développement assisté par IA.
Le principe est simple : la spécification devient la référence du projet. Elle décrit ce qui doit être livré avant que l’IA ne produise du code. À partir de là, le travail est découpé, suivi dans GitHub, vérifié par la CI et relié à des tests.
Pour un décideur, l’intérêt est surtout là : garder la maîtrise du besoin, savoir où en est réellement le projet et conserver une trace exploitable des décisions prises.
L’IA peut accélérer l’exécution. Le SDD évite qu’elle accélère aussi les écarts de compréhension. Et cette constatation est valable lors de la migration d’un projet Windev .
Le Spec-Driven Development comme cadre de travail
Dans un fonctionnement classique assisté par IA, on peut être tenté de partir d’une consigne générale, puis de laisser le modèle produire du code, des fichiers et parfois même une architecture.
Sur un projet métier, le risque apparaît vite : le modèle complète les zones floues avec ses propres hypothèses.
Nous préférons partir d’une spécification versionnée. Cette spec devient le point de référence pour le client, l’équipe EloNeva et les agents IA.
Elle décrit ce que la fonctionnalité doit faire, ses contraintes, ses règles métier et les conditions dans lesquelles elle pourra être considérée comme terminée.
À ce stade, l’IA n’est pas encore en train de développer. Elle aide d’abord à structurer le travail.
L’humain reste présent aux étapes qui engagent le projet
Le premier élément qui distingue notre méthode est la place donnée à l’humain.
Nous gardons trois points de contrôle structurants :
- la revue de la spécification ;
- la validation du plan de développement ;
- la review de la Pull Request.
La revue de la spec permet de vérifier que le besoin métier a été correctement compris.
La validation du plan sert à contrôler le découpage proposé : ordre des travaux, dépendances, critères d’acceptation et priorités.
La review de la PR sert à valider le résultat avant intégration.
Selon les exigences du client, cette dernière étape peut être automatisée. Le niveau d’automatisation est défini avec lui, pas supposé.
Certains contextes imposent une validation humaine systématique. D’autres peuvent accepter une review automatisée si les règles de qualité, de sécurité, de tests et de conformité sont suffisamment définies.
De la spécification au plan de développement
Une fois la spec validée, l’IA peut proposer un plan.
Ce plan transforme le besoin en unités de travail compréhensibles par une équipe de développement.
Nous utilisons une logique d’epic et de sub-issues.
L’epic porte la fonctionnalité ou le lot fonctionnel. Les sub-issues décrivent les capacités livrables, avec leurs dépendances et leurs critères d’acceptation.
Par exemple :
Epic : gérer une inscription à une newsletter
T01 — stocker les inscriptions
T02 — exposer l'API d'inscription
T03 — intégrer le formulaire
T04 — vérifier les cas d'erreur
Le plan peut être produit par l’IA. Il n’est pas publié automatiquement.
Il est relu.
C’est important parce qu’un découpage techniquement cohérent peut malgré tout passer à côté d’une contrainte métier, d’une priorité client ou d’une dépendance réelle.
Une traçabilité complète, de l’exigence au test
Le deuxième élément important de la méthode EloNeva est la traçabilité.
Nous cherchons à pouvoir répondre à une question simple : quelle preuve montre que cette exigence a bien été satisfaite ?
La chaîne de traçabilité suit le projet de bout en bout :
exigence métier
→ spécification
→ epic
→ sub-issue
→ critère d'acceptation
→ code
→ test
→ Pull Request
→ CI
Cela évite deux situations fréquentes.
La première : une fonctionnalité existe dans le code, mais personne ne sait exactement quelle demande métier elle couvre.
La seconde : un ticket est marqué comme terminé, mais il n’existe aucune preuve claire que ses critères d’acceptation sont respectés.
Pour les critères automatisables, nous cherchons à relier explicitement le critère au test qui le prouve.
CA1 — une adresse email déjà inscrite est refusée
Puis dans les tests :
it('CA1 — refuse un email déjà inscrit', async () => {
// vérification du comportement attendu
})
Pour un décideur, l’intérêt n’est pas le nom du test. C’est la possibilité de suivre une exigence jusqu’à une preuve vérifiable.
GitHub comme colonne vertébrale du processus
Le troisième point distinctif est l’ancrage du processus dans GitHub.
Nous utilisons GitHub pour conserver l’état du travail et l’historique des décisions :
- les epics pour porter les ensembles fonctionnels ;
- les sub-issues pour le découpage du développement ;
- les Projects pour suivre les statuts et les priorités ;
- les branches et Pull Requests pour les changements de code ;
- la CI pour exécuter les contrôles automatiques.
L’intérêt est d’avoir un système partagé.
Le client ou le chef de projet suit l’avancement au niveau fonctionnel. L’équipe technique travaille sur les tickets. Les agents IA utilisent les mêmes objets. Les tests et les contrôles CI restent attachés au même flux.
Nous évitons ainsi de créer un processus parallèle réservé à l’IA.
Si demain le modèle ou l’assistant change, le projet reste lisible.
Des critères d’acceptation qui servent réellement
Un critère d’acceptation sert à décider si le travail peut être considéré comme terminé.
Nous distinguons les critères automatisables de ceux qui demandent un jugement humain.
Un critère automatique peut être vérifié par un test :
CA1 auto — une requête invalide retourne une erreur
Un critère manuel peut concerner une validation métier ou ergonomique :
CA2 manuel — le message affiché est compréhensible pour l'utilisateur
Cette séparation permet d’automatiser ce qui peut l’être sans masquer ce qui nécessite encore une décision humaine.
Elle prépare aussi la review de la PR.
La CI peut prouver que les tests passent. Elle ne remplace pas forcément le regard métier.
Les agents IA interviennent dans un cadre défini
Une fois le plan validé et les tickets publiés, les agents peuvent intervenir sur le développement.
Ils peuvent modifier le code, lancer les tests, préparer les commits, documenter leur travail et transmettre le contexte d’un agent au suivant.
Leur marge de manoeuvre reste définie par le ticket et la spec.
S’ils rencontrent une ambiguïté, le bon comportement n’est pas de réécrire silencieusement le besoin.
La méthode doit faire remonter l’écart.
C’est particulièrement important lorsqu’une spécification évolue pendant le développement.
Un ticket déjà démarré ne doit pas être modifié rétroactivement comme si la nouvelle exigence avait toujours existé. Une évolution peut être créée, un amendement proposé ou une alerte remontée selon le cas.
Cette discipline évite de perdre l’historique réel du projet.
La CI transforme la validation en preuve
Avant une PR, le projet peut exécuter automatiquement les tests, le lint, le typecheck et les contrôles propres à la stack.
L’objectif est de ne pas considérer qu’un ticket est terminé sur la seule base du code produit.
La CI fournit des preuves reproductibles.
Pour une direction ou un responsable de projet, cela apporte de la fiabilité dans le suivi. Une tâche n’avance pas uniquement parce qu’un agent ou un développeur affirme qu’elle est finie. Une partie du statut repose sur des contrôles objectifs.
La review de PR : humaine ou automatisée selon le contexte
Par défaut, nous gardons une review humaine de la Pull Request.
Elle permet de relire les choix techniques, de vérifier les critères manuels et de valider que le résultat reste cohérent avec le besoin.
Mais ce point peut évoluer selon le projet.
Certains clients souhaitent conserver une validation humaine systématique.
D’autres peuvent accepter une review automatisée, à condition que les contrôles soient suffisamment définis : qualité du code, respect des conventions, couverture des tests, sécurité, critères d’acceptation.
L’important est de savoir précisément qui valide quoi, avec quelles règles et avec quelles preuves.
Ce que cette méthode change pour un décideur
Le bénéfice principal du SDD n’est pas d’écrire davantage de code avec l’IA.
Il est de garder le projet pilotable alors que l’exécution devient plus rapide.
Avec cette méthode, un décideur peut retrouver :
- le besoin d’origine ;
- le plan retenu ;
- les tickets associés ;
- leur état dans le Project ;
- les critères qui conditionnent leur validation ;
- les tests qui prouvent les comportements attendus ;
- la PR qui porte les changements ;
- les contrôles CI exécutés avant intégration.
Cette visibilité compte lorsque plusieurs intervenants, humains ou agents IA, travaillent sur le même projet.
Elle facilite aussi les audits, les reprises de projet et les évolutions futures.
Une méthode qui reste valable si les outils changent
Nous ne voulons pas que notre méthode dépende d’un modèle ou d’un assistant particulier.
Les outils d’IA évoluent vite. Les modèles aussi.
Le Spec-Driven Development reste valable parce qu’il repose sur des objets durables : une spécification, un plan, des tickets, des critères, du code, des tests et une PR.
L’IA intervient dans ce système.
Elle ne devient pas le système.
Pour EloNeva, c’est une condition importante pour intégrer l’IA dans des projets métier qui doivent rester maintenables, compréhensibles et auditables dans le temps.
Conclusion
Notre méthode de développement IA est une application du Spec-Driven Development adaptée aux projets que nous menons chez EloNeva.
La spécification sert de référence. L’IA aide à produire le plan et à exécuter le développement. L’humain intervient aux étapes clés : revue de la spec, validation du plan et review de la PR, sauf lorsqu’un autre niveau d’automatisation a été défini avec le client.
GitHub porte le suivi opérationnel avec les epics, sub-issues, Projects et Pull Requests. La CI et les tests fournissent les preuves.
Pour un décideur, l’intérêt est direct : profiter de la capacité d’exécution de l’IA sans perdre la maîtrise du besoin, du suivi et de la validation.